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Abstract 

This  report  describes  a  framework  for  representing  and  validating  formal  proofs  in  various  ax¬ 
iomatic  systems.  The  framework  is  based  on  the  Edinburgh  Logical  Framework  (LF)  but  is  op¬ 
timized  for  minimizing  the  size  of  proofs  and  the  complexity  of  proof  validation,  by  removing 
redundant  representation  components.  Several  variants  of  representation  algorithms  are  presented 
with  the  resulting  representations  being  a  factor  of  15  smaller  than  similar  LF  representations. 
The  validation  algorithm  is  a  reconstruction  algorithm  that  runs  about  7  times  faster  than  LF 
typechecking.  We  present  a  full  proof  of  correctness  of  the  reconstruction  algorithm  and  hints  for 
the  efficient  implementation  using  explicit  substitutions.  We  conclude  with  a  quantitative  analysis 
of  the  algorithms. 
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1  Introduction 


The  problem  of  theorem  proving  has  received  significant  attention  from  the  scientific  community 
in  the  last  30  years,  mostly  as  a  critical  component  of  program  verification.  The  most  often 
analyzed  aspect  of  theorem  proving  has  been  the  most  challenging  one,  namely  the  efficiency  and 
practicality  of  the  proof  search.  Much  less  attention  has  been  devoted  to  the  problem  of  producing 
and  manipulating  the  proofs  of  the  proved  theorems. 

A  typical  theorem  prover  provides  a  counterexample  for  each  failed  theorem  but  it  does  not 
emit  a  proof  of  the  theorem  in  case  of  success.  This  means  that  users  of  such  theorem  provers 
are  obligated  to  take  on  faith  their  soundness.  This  is  a  significant  problem,  because  powerful 
theorem  provers  are  complex  systems,  with  very  com])licated  invariants  that  are  easy  to  break 
during  implementation  or  maintenance.  Furthermore,  theorem  prover  bugs  might  persist  for  a  long 
time  because  the  user  does  not  usually  have  a  simple  criterion  to  distinguish  between  theorems  that 
should  succeed  and  those  that  should  not.  Because  of  these  reasons  we  believe  that  it  is  useful  to 
instrument  a  theorem  prover  to  emit  a  proof  for  every  theorem  that  it  proves.  The  proof  should 
be  detailed  enough  so  that  it  can  be  checked  by  a  very  simple  and  easy-to-trust  proof  checker. 

Adding  the  proof-generating  capability  to  a  theorem  prover  not  only  makes  it  easier  to  verify 
and  to  maintain,  but  also  enables  its  use  as  a  front-end  to  a  Proof-Carrying  Code  (PCC)  [12]  system 
for  the  safe  execution  of  untrusted  code.  PCC  is  a  protocol  by  which  two  software  systems  (say 
a  code  producer  and  a  code  consumer)  can  cooperate  on  the  task  of  convincing  the  code  consumer 
that  a  program  supplied  by  the  untrusted  code  producer  is  safe  to  run.  The  key  element  of  the  PCC 
technique  is  that  the  producer  must  supply  together  with  the  program  a  formal  safety  proof  stating 
the  the  execution  of  the  program  does  not  violate  the  safety  policy  of  the  code  consumer.  Then  the 
server  can  easily  validate  the  safety  proof  before  installing  the  untrusted  code  for  execution.  PCC 
has  uses  ranging  from  operating  system  kernel  extensions  to  mobile  code  and  safe  inter-operation 
of  components  written  in  safe  and  unsafe  languages  [12,  13,  14].  In  all  of  these  situations,  it  is 
important  to  have  compact  representation  of  proofs  because  they  are  explicitly  manipulated  and 
possibly  sent  through  communication  networks.  For  the  PCC  technique  to  be  practical  it  is  also 
important  to  be  able  to  validate  the  proofs  quickly. 

The  purpose  of  this  report  is  to  present  efficient  algorithms  for  the  representation  and  validation 
of  proofs.  These  algorithms  were  developed  as  part  of  our  PCC  implementation  eflPort,  which  is 
currently  based  on  first-order  logic.  Even  though  the  algorithms  are  optimized  and  validated 
experimentally  for  first-order  logic,  they  are  usable  for  other  logics  as  well. 

There  are  two  main  factors  that  have  guided  our  choices  for  a  proof  representation  algorithm: 
generality  and  the  ability  to  handle  higher-order  representation.  Each  of  these  factors  are  motivated 
below. 

The  first  impulse  in  designing  an  efficient  proof  representation  and  validation  algorithms  is  to 
specialize  them  to  a  given  logic.  For  example,  we  might  define  the  representation  and  validation 
algorithm  by  cases,  with  one  case  for  each  inference  rule  in  the  logic.  This  approach  has  the  major 
disadvantage  that  a  new  representation  and  validation  algorithm  has  to  be  designed  and  imple¬ 
mented  for  each  logic.  We  would  prefer  instead  to  use  general  algorithms  that  are  parameterized 
by  the  particular  logic  of  interest. 

A  simplistic  view  of  a  proof  is  as  a  tree,  whose  leaves  represent  uses  of  axioms  and  whose 
internal  node  represent  uses  of  inference  rules.  If  we  label  each  node  with  the  predicate  proved 
by  the  subtree  rooted  at  that  node  we  can  then  check  the  validity  of  the  proof  by  verifying  that 
each  node  is  a  valid  instance  of  an  inference  rule.  Unfortunately,  this  is  not  quite  enough  for  a 
large  class  of  logics  that  have  parametric  and  hypothetical  judgments.  For  example,  the  implication 
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introduction  rule  of  first-order  logic  specifies  that  the  left-hand  side  of  the  implication  can  be  used 
as  an  assumption  but  only  in  the  subtree  that  proves  the  right-hand  side.  This  side-condition  can 
be  expressed  naturally  using  a  binding  proof  constructor  that  binds  the  assumption  of  the  left-hand 
side  in  the  proof  of  the  right-hand  side. 

To  achieve  both  the  generality  and  the  higher-order  representation  goals  we  use  the  Edinburgh 
Logical  Framework  (LF)  [5]  introduced  by  Harper,  Honsell  and  Plotkin  as  a  general  framework  for 
defining  logics.  LF  is  general  in  the  sense  that  implementation  of  validation  and  representation  is 
parameterized  by  the  logic  of  interest.  Section  3  presents  the  logical  framework  and  how  it  can  be 
used  to  validate'  proofs. 

The  major  drawback  of  representing  proofs  in  LF  is  that,  in  general,  the  representations  are 
unnecessarily  large'  and  difficult  to  check  because  of  many  redundant  components.  To  address  this 
problem  we'  intre)elue:e  in  Section  5  the  framework  LFj,  a  variant  of  LF  that  can  deal  with  represen¬ 
tations  whe're’  re'elundant  components  have  been  erased.  We  present  in  Sections  5  and  6  a  validation 
algorithm  for  LF,  and  then  in  Section  7  several  algorithms  that  transform  a  LF  representation  to 
the  LF,  implie-it  re'jnesentation. 

The  ad('(iuacy  of  representing  logical  derivation  in  LF  is  proved  in  [5].  In  Section  8  we  redo 
the  proofs  for  tin*  LF,  representations.  This  section  is  very  technical  and  can  be  skipped  on  the 
first  reading.  The  proof  of  correctness  motivates  the  design  of  the  reconstruction  and  validation 
algorithms  and  ('xposes  opportunities  for  optimizations.  A  basic  understanding  of  this  section  is 
required  for  writing  a  good  implementation  of  the  representation  and  validation  algorithms  and 
also  for  understanding  of  the  optimizations  presented  in  Section  9. 

In  Sections  9  and  10  we  consider  practical  aspects  related  to  the  concrete  implementation  of  the 
representation  and  validation  algorithms.  The  implementation  is  based  on  explicit  substitutions  to 
minimize  the  time  and  space  required  for  proof  validation. 

Finally,  in  Section  11  we  show  quantitative  comparisons  between  the  LF  and  LFj  sizes  of 
representations  and  speed  of  validation  algorithms.  The  performaiice  results  can  be  summarized  by 
saying  that  the  implicit  representation  is  on  the  average  15  times  smaller  than  the  LF  representation 
and  validating  it  is  on  the  average  7  times  faster.  Moreover  these  improvements  seem  to  increase 
for  larger  problems,  reaching  factor  of  44  for  the  size  and  18  for  the  time,  for  the  largest  PCC 
experiments  to  date.  Following  these  performance  results  we  evaluate  the  various  optimizations 
presented  in  Section  9,  showing  that  they  roughly  halve  the  space  and  time  requirements  of  LFj 
proof  validation. 
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2  A  First-Order  Predicate  Logic  C 

For  illustration  purposes  we  introduce  in  this  section  a  fragment  of  the  first-order  predicate  logic. 
In  the  rest  of  this  paper  we  will  refer  to  this  logic  as  C,  The  syntactic  elements  of  £  are  grouped 
in  two  levels:  expressions  and  predicates.  The  language  of  expressions  includes  integer  variables, 
literals,  addition  and  subtraction: 

e  ::=  a:  I  n  I  ei  +  62  I  ei  -  62 

The  language  of  predicates  is  essentially  a  fragment  of  first-order  predicate  logic  that  includes 
the  predicate  true,  conjunction,  implication,  universal  quantification  and  expression  equality: 

P  ::=  true  |  Pi  A  P2  |  Pi  D  P2  |  Vji.P  |  61  =  62 

This  subset  of  first-order  predicate  logic  is  sufficient  for  our  purposes.  However  the  logic  can 
be  extended  in  two  ways.  One  is  to  allow  other  boolean  connectives  such  as  negation,  disjunction 
and  existential  quantification.  The  other  opportunity  for  extension  is  to  add  new  function  symbols 
at  the  level  of  expressions  and  predicates.  Such  extensions  of  £  can  be  expressed  in  the  framework 
presented  in  the  rest  of  this  report  by  treating  new  expression  and  predicate  constructors  following 
the  model  of  constructors  already  existent  in  £. 

2.1  The  Proof  System 

The  proof  system  of  £  is  the  collection  of  axioms  and  inference  rules  that  define  the  valid  deriva¬ 
tions.  Not  surprisingly  the  proof  system  is  composed  of  two  orthogonal  components.  The  first 
component  contains  the  first-order  predicate  logic  rules  and  the  other  gives  an  interpretation  to 
integer  arithmetic  functions.  We  write  >  P  when  the  predicate  P  can  be  proved  using  the  proof 
rules  in  £. 

Figure  1  shows  the  inference  rules  of  first-order  predicate  logic  from  £.  In  an  extended  logic, 
negation,  disjunction  and  existential  quantification  rules  must  be  added. 


>  true 


trueJ 


>  Pi  >  P2  ^  .  >  Pi  A  P2  ^1 

- -p  .  jy  and-1  - ^-75 — ^and_el 

E>  Pi  A  P2  >  Pi 


>  Pi  A  P2 
>  P2 


and_er 


>Pi 


•u 


>  Pi  D  P2 


>Pi 


>  P2 


impLe 


V 

•u 


t>Va;.P  >[e/x]P 


Figure  1:  Fragment  of  the  first-order  predicate  logic  proof  rules. 

The  choice  of  axioms  for  dealing  with  integer  arithmetic  is  a  delicate  one.  We  do  not  attempt 
here  to  have  a  complete  logic  but  one  that  is  suitable  for  illustrating  the  proof  representation  and 
validation  framework  presented  in  the  rest  of  this  report.  Soundness  of  the  logic  is  also  not  crucial 
for  our  purposes,  but  is  a  desirable  feature.  Figure  2  shows  our  choice  of  arithmetic  axioms. 

As  an  example  of  a  derivation  in  £  consider  the  proof  of  P  =  V6i.Ve2.V63.(ei  =  62  +  63)  D 
(ei  —  63  =  62).  The  derivation  V  of  the  predicate  P  is  shown  in  tree  form  in  Figure  3.  We  will 
return  to  this  derivation  in  the  following  sections  to  exemplify  the  various  proof  representations 
and  the  behavior  of  corresponding  validation  algorithms. 
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H-com 
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>  (El  +  E2)  +Ez  =  Ei  +  {E2  +  Es)  ^  >  {El  E2)  -E3  =  Ei  +  {E2  -  E^) 

Figure  2:  Arithmetic  proof  rules. 
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>  63  =  63 


>  61  -  63  =  (62  -I-  63)  -  63 


=id 

-congr 


PI" 

>  (62  +  63)  - 


63  =  62 


>  61  -  63  =  62 


V  = 


>  61  =  62  -I-  63  D  61  -  63  =  62 
>  V63.  61  =  62  -I-  63  D  61  -  63  =  62 
>  Ve2.V63.  61  =  62  -(-  63  D  61  -  63  =  62 


>  V61.V62.V63.  61  =  62  -I-  63  D  61  —  63  =  62 


impU“ 

-alU^3 

-alU*2 


=tr 


V^  = 


=id 


-inv 


>  62  —  €2  >  es  —  es  =  0  .  ,  .  j 

>e.  +  ll  =  e.+-^ 

- 7 - r - 7 - 7+- assoc  - —7 - r - =tr 

>  (62  +  63)  -  63  =  62  +  (63  -  63) _ >  62  +  (63  --  €3)  =  €2 _ 

r>  ( P.n  —  P.o  Pn 


Figure  3:  The  derivation  V  of  Vei.Ve2.Ve3.(ei  =  e2  +  63)  D  (ei  —  63  =  e^)  in  L.  For  typographical 
reasons  the  subderivation  V\  is  shown  as  a  separate  tree. 
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3  The  Edinburgh  Logical  Framework 

The  Edinburgh  Logical  Eramework  (also  referred  to  as  LF)  has  been  introduced  by  Harper,  Honsell 
and  Plotkin  [5]  as  a  metalanguage  for  high-level  specification  of  logics.  LF  provides  natural  support 
for  the  management  of  binding  operators,  hypothetical  and  schematic  judgments.  For  example  it 
captures  the  convention  that  expressions  that  differ  only  in  the  names  of  bound  variables  are 
considered  identical.  Similarly,  it  allows  direct  expression  of  contexts  and  variable  lookup  as  they 
arise  in  a  hypothetical  and  parametrical  judgment.  The  fact  that  these  techniques  are  supported 
by  the  logical  framework  is  a  crucial  factor  for  the  succinct  formalization  of  proofs. 

The  LF  representation  of  a  logic  consists  of  two  stages.  The  first  stages  is  the  representation  of 
the  abstract  syntax  of  the  logic  under  investigation.  For  examples  we  will  show  how  to  represent 
expressions  and  predicates  of  C  in  LF.  The  second  stage  is  the  re})resentation  of  the  semantics  of 
C.  We  do  this  by  representing  in  LF  the  proof  rules  set  C.  Then  we  show  how  actual  proofs  can 
be  constructed  from  instances  of  proof  rules. 

The  LF  type  theory  is  a  language  with  entities  of  three  levels:  objects,  types  and  kinds.  Types 
are  used  to  qualify  objects  and  similarly,  kinds  are  used  to  qualify  ty])es.  The  abstract  syntax  of 
these  entities  is  shown  below: 


Kinds 

K 

::=  Type 

1  Ux-.A.K 

Types 

A 

a  | 

AM  1  Ilx:Ai.A2 

Objects 

M 

::=  X  1 

c  1  M1M2  1  Xx-.AM 

Here  Type  is  the  base  kind,  a  is  a  type  constant  and  c  is  an  object  constant. 

We  represent  our  logic  in  LF  by  means  of  a  signature  S  that  assigns  types  to  a  set  of  constants 
describing  the  syntax  of  expressions  and  predicates,  and  the  proof  rules  of  our  logic.  Then  we  define 
a  representation  function  that  will  map  expressions,  predicates  and  their  proofs  in  our  logic  to  LF 
objects  constructed  with  constants  declared  in  the  signature  S. 

The  main  representation  strategy  in  LF  is  that  judgments  (e.g.,  statements  about  the  validity 
of  predicates)  are  represented  as  LF  types  and  judgment  derivations  (e.g.  a  proof  of  a  predicate) 
are  represented  as  objects  whose  type  is  the  representation  of  the  judgments  they  prove.  Type 
checking  in  the  LF  type  discipline  can  then  be  used  to  check  the  validity  of  logic  proofs. 

We  start  now  to  present  the  signature  S  corresponding  to  the  logic  £. 

3.1  Representing  Abstract  Syntax:  Expressions  and  Predicates 

First,  we  define  in  Figure  4  the  LF  types  exp  of  expressions  and  pred  of  predicates.  All  of  these 
are  atomic  LF  types  of  base  kind  Type. 


exp  :  Type 
pred  :  Type 

Figure  4:  the  LF  signature  E  (part  1).  Base  type  constants. 

Then  for  each  expression  and  predicate  constructor  we  define  an  LF  constant  as  shown  in 
Figure  5.  One  of  the  most  interesting  cases  is  the  universal  quantification.  Care  must  be  taken 
when  dealing  with  universal  quantification  because  of  the  presence  of  bound  variables.  For  example, 
we  must  ensure  that  the  representation  captures  the  fact  that  the  bound  variable  is  local  to  the  body 
of  the  quantification  and  that  two  expressions  differing  only  in  the  name  of  the  bound  variables  are 


7 


equal.  Moreover,  when  an  expression  is  substituted  for  the  bound  variable  we  must  ensure  that  no 
free  variable  of  the  substituted  expression  is  captured. 

One  of  the  main  reasons  we  chose  LF  as  a  proof  representation  language  is  that  it  provides 
mechanisms  for  dealing  with  bound  variables.  Note  in  Figure  5  how  the  universal  quantification  is 
represented  as  a  higher-order  construct  by  representing  the  bound  logical  variable  by  a  bound  LF 
variable.  This  effectively  delegates  all  the  tedious  manipulations  of  bound  variables  to  LF. 

0  :  exp 

-h  :  exp  exp  ->  exp 

—  :  exp  exp  exp 

=  :  exp  exp  — >  pred 

<>  :  exp exp  pred 

true  :  pred 

and  :  pred  pred  pred 

impl  :  pred  pred  pred 

all  :  (exp  — >  pred)  ->  pred 

Figure  5:  The  LF  signature  S  (part  2).  Expression  and  predicate  constructors. 

The  LF  representation  function  is  defined  inductively  on  the  structure  of  expressions,  types 
and  predicates  as  shown  in  Figures  6  and  7. 

=  X 

'"ei  +  62^  ==  +  '"ei"'  ^62“' 

■“ei  —  62"'  =  —  '”62"' 

Figure  6:  LF  representation  (part  1).  Expressions. 


i-ei  =  e2~' 

r 

(M 

L 

r 

L 

11 

11 

^ei  ^  62-- 

=  <>  '"ei"'  '"62"' 

'"true"' 

=  true 

■"P 

=  and'"P^^P^ 

^pdp^ 

=  impl^P"""P^ 

^Vx.P"' 

=  all  (Ax: exp. '"P"’) 

Figure  7:  LF  representation  (part  2).  Types  and  predicates. 

3.2  Representing  Semantics:  Proofs 

Up  to  this  point  we  have  defined  the  representation  of  expressions,  types  and  predicates  in  LF. 
Our  ultimate  goal  is  to  be  able  to  represent  proofs  of  predicates  or  equivalently  derivations  of  the 
validity  of  predicates.  We  follow  the  same  pattern  as  for  syntactic  constructs  and  we  introduce 
a  type  of  proofs  pf  and  then  define  each  proof  rule  as  an  LF  constant  of  this  type.  Things  are 
actually  more  involved  due  to  the  fact  that  we  want  the  type  of  a  proof  to  determine  the  predicate 
that  is  being  proved.  In  this  way  we  verify  by  type  checking  not  only  that  a  proof  is  valid  but  also 
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true_i 

and-i 

and_el 

and-er 

impl-i 

impl.e 

all-i 

all_e 


pf  true 

nprpred.IIr  :pred.pf  p  — pf  r  ^  pf  (andp  r) 
Xlprpred.Ilr  ipred.pf  (andp  r)  ->  pf  p 
np:pred.nr  ipred.pf  (andp  r)  ->  pf  r 
nprpred.rir  :pred.(pf  p  -)►  pf  r)  pf  (implp  r) 
nprpred.rir  ipred.pf  (impl  p  r)  pf  p  — pf  r 
lip: exp  pred.(n'y  lexp.pf  (p  pf  (all  p) 

lip: exp  — pred.ne:exp.pf  (all  p)  pf  (p  e) 


Figure  8:  The  LF  signature  S  (part  3).  First-order  logic  proof  constants  (see  Figure  1). 


id 

=  sym 
=  tr 
-hid 
-hcom 
-f  inv 
-tcongr 

“Congr 

-hassoc 
H —  assoc 


ne:exp.pf  (=  e  e) 

Uei  :exp.ne2:exp.pf  {=  62  ei)  ->  pf  (=  ei  62) 

Ilei  :exp.ne2  :exp.ne3  :exp.pf  (=  ei  62)  pf  (=  62  63)  pf  (=  ei  63) 
ne:exp.pf  (=  (-f  e  0)  e) 

Ilei  :exp.ne2:exp.pf  (=  (+  ei  62)  (+  62  ei)) 
ne:exp.pf  (=  (—  e  e)  0) 

Ilei  •  exp.ne2 :  exp.IIe'i :  exp.IIe^ :  exp. 

pf  (=  ei  62)  ->■  pf  (=  e[  62)  ^  pf  (=  (+  ei  e[)  (+  62  e^)) 

Hex :  exp.ne2 :  exp.IIe^  :  exp.He^ :  exp, 

pf  (=  ei  62)  pf  (^  e'l  e'2)  pf  (=  (-  ei  e[)  (-  62  62)) 

Hex  :exp.ne2: exp. lies: exp.pf  (=  (H-  (-h  ei  62)  63)  (H-  ei  {+  62  63))) 

Hex  :exp.ne2: exp. lies: exp.pf  (=  (-  (+  ex  62)  63)  (-h  ei  (-  62  63))) 


Figure  9:  The  LF  signature  S  (part  4).  Application-specific  proof  constants  (see  Figure  2). 


that  it  proves  the  desired  predicate.  This  is  possible  to  express  in  the  LF  type  discipline  by  using 
type  families  indexed  by  terms. 

Thus  pf  is  actually  a  type  family  indexed  by  LF  representation  of  predicates: 

pf  :  pred  Type 

Following  the  model  of  expressions  and  predicates  we  add  to  the  signature  S  a  constant  for  each 
proof  rule  in  C.  The  constants  corresponding  to  the  proof  rules  used  by  our  example  are  shown  in 
Figure  8  (first-order  logic  proof  rules)  and  Figure  9  (arithmetic  proof  rules). 

We  then  extend  the  representation  function  to  derivations.  When  doing  so  care  must 
be  taken  with  hypothetical  and  schematic  judgments,  such  as  the  implication  introduction  and 
the  universal  quantification  introduction  rules.  We  show  in  Figure  11  the  representation  of  the 
introduction  rules  for  conjunction,  implication  and  universal  quantification.  The  representation  of 
the  conjunction  introduction  is  typical  for  all  other  rules  not  shown  here,  including  the  arithmetic 
proof  rules. 

The  implication  introduction  rule  introduces  the  hypothesis  labelled  u  for  the  purpose  of  deriving 
P2.  Checking  an  instance  of  this  rule  schema  involves  verifying  that  it  discharges  properly  the 
hypothesis  u.  Equivalently,  the  derivation  Vu  must  be  hypothetical  in  u.  This  is  expressed  naturally 
in  LF  by  representing  the  hypothesis  as  a  variable  bound  in  the  derivation  Finally,  the  LF 
representation  of  our  logic  contains  also  the  representation  of  the  application-specific  proof  rules. 
Their  representation  is  straightforward  because  they  do  not  involve  hypothetical  judgments.  As  an 
example  we  show  below  the  LF  representation  of  the  symmetry  rule  for  equality:. 
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V 


n 


>e;  =  ei  =  =  -symrerV-V- 

Figure  10;  LF  representation  (part  4).  Fragment  of  the  application-specific  rule  representation  (see 
Figure  2). 


r  n 

©1  V2 


>  Pi _ >  P2 

t>  Pi  A  P2 

r  “I 

t>  Pi 


=  and_i  ^Pr  ^P2^ 


=  impl.i  '■Pr  (Aw:pf 

r  “1 

(AartexpPP,.'')  (A?;:expPP"'') 


Figure  11;  LF  representation  (part  3).  Fragment  of  the  first-order  logic  rule  representation  (see 
Figure  1). 


As  an  example  of  a  proof  representation  in  LF  we  show  in  Figure  12  the  representation  of  the 
proof  P  from  Figure  3  of  the  predicate  Vei.Ve2-Ve3.(ei  ==  62  +  es)  D  (ei  —  es  =  62)-  The  LF 
representation  of  the  proof  is  computed  as  '~P~^  from  the  representation  in  tree  form.  Compare  this 
LF  representation  to  the  proof  in  tree  form  as  shown  in  Figure  3.  The  only  difference  is  the  syntax 
used  to  express  the  proof  and  it  seems  obvious  how  one  could  reconstruct  the  tree  form  of  the  proof 
from  the  LF  representation. 

In  the  next  section  we  show  a  simple  algorithm  that  can  be  used  to  validate  proof  representa¬ 
tions.  The  algorithm  is  parameterized  by  the  signature  E  and  therefore  can  be  reused  for  checking 
validity  of  derivations  in  other  logics  just  by  changing  the  LF  representation  signature. 

4  Type  Checking  in  the  LF  Type  System 

One  of  the  advantages  of  using  LF  for  proof  representation  is  that  proof  validity  can  be  determined 
by  a  simple  type-checking  algorithm.  That  is,  to  check  that  the  LF  object  M  is  the  representation 
of  a  valid  proof  of  the  predicate  P  we  use  the  LF  typing  rules  (to  be  presented  below)  to  verify 
that  M  has  type  pf  '"P"'  in  the  context  of  the  signature  S  defining  the  valid  proof  rules. 

In  order  to  define  the  typing  rules  we  must  formalize  the  syntax  of  signatures  and  we  also 
introduce  typing  contexts  that  assign  types  to  free  variables: 

E  ::=  •  I  Ti,a:K  \  T>,c:A  Signatures 

r  ::=  •  I  r,  a;:d.  Contexts 
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We  define  the  typing  judgment  for  LF  objects  in  terms  of  three  additional  judgments  as  shown 
below: 

T  ^  M  :  A  M  is  a  valid  object  of  type  A 
A  \  K  A  is  a  valid  type  of  kind  K 
A=i^  B  A  is  /3-equivalent  to  B 
M  =0  N  M  is  /3-equivalent  to  N 

The  complete  LF  type-system  defines  also  a  typing  judgment  for  kinds.  We  omit  this  judgment 
here  because,  for  the  purpose  of  checking  the  validity  of  proofs,  kinds  can  be  assumed  to  be  well- 
typed.  In  particular  the  only  kinds  relevant  to  checking  proofs  are  the  base  kind  and  the  kinds 
associated  with  the  type-constants  in  the  signature  S,  all  of  which  can  be  trusted  to  be  well- typed. 
For  the  signature  corresponding  to  the  logic  C  these  kinds  are  Type  and  pred  Type,  which  are 
obviously  well-typed. 

We  show  in  Table  1  the  definition  of  the  judgments  introduced  above.  For  the  ^-equivalence 
judgment  we  omit  the  rules  that  define  it  to  be  an  equivalence  and  a  congruence. 

Types  : 

E{a)=K  TFA-.Ux:B.K  T  F  M  :  B  T  ^  :  Type  T,  x  :  A  5  :  Type 
VFa-.K  TF  AM  :[M/x]K  T  F  UxiA.B  ■.Type 

Objects  : 

^{c)  =  A  r(a;)  =  A  T,x:AFM:B 
TF  C-.  A  VF  Xx-.A.M  -.Jlx-.A.B 

TF  M  :Yix-.A.B  TFN:A  VFM:A  A=0B 
V  F  MN  :  [Nlx\B  VF  M:B 

Equivalence  : 

{Xx:AM)N  =0  [N/x]M 

Table  1:  Type  checking  in  the  LF  type  discipline 

The  following  theorems  can  be  proven  using  techniques  which  are  similar  to  those  used  in  [5,  13]. 
These  theorems  establish  that  LF  type-checking  is  an  adequate  procedure  for  checking  the  validity 
of  LF  representations  of  proofs  in  C.  As  mentioned  before,  the  adequacy  of  LF  type-checking  holds 
even  if  £  is  extended  with  additional  boolean  connectives  and  function  symbols.  The  adequacy 
holds  even  for  higher-order  logics  [5]. 

Theorem  4.1  (Adequacy  of  Expression  Representation.) 

1.  If  e  has  free  variables  among  Xi, . . . ,  Xn,  then  Xi  :  exp, . . . ,  iPn  •  exp  '”e"'  :  exp. 

2.  If  M  is  an  LF  object  such  that  xi  :  exp, . . .  ^Xn  :  exp  Fm  :  exp,  then  exists  an  expression  e 
with  free  variables  among  xi,...,Xn  such  that  ’’e"'  M. 

Theorem  4.2  (Adequacy  of  Predicate  Representation.) 

1.  If  P  has  free  variables  among  xi,...,Xn,  then  Xi  :  exp, . ..  ,Xn  ■  exp  F  '‘P’’  :  pred. 
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2.  If  M  is  an  LF  object  such  that  Xi  :  exp, . . . ,  :  exp  M  :  pred,  then  there  exists  a  predicate 

P  with  free  variables  among  ,Xn  such  that  =0  M, 

Theorem  4.3  (Adequacy  of  Derivation  Representation.) 

L  If  V  ::  >  V  is  a  derivation  of  P  with  parameters  vi  (i  —  and  from  hypotheses 

Uj  ::  ^  Pj  —  1, . . . ,  m^)  then  vi  :  exp,  Uj  :  pf  ^Pj~^  :  pf  ^P^. 

2.  If  M  is  an  LF  object  such  that  Vi  :  exp,Wj  :  pf  ^Pj~^  M  :  pf  '"P”’,  then  there  exists  a 
derivation  V  ::  \>  V  of  P  with  parameters  Vi  (z  —  and  from  hypotheses  Uj  ::  >  Pj 

(j  =  1 , . . , ,  such  that  =0  M, 


Th(‘  reason  for  the  asymmetry  in  the  statement  of  the  adequacy  theorems  above  is  that  while  the 
r(*|)n*seiitation  of  an  expression,  predicate  or  derivation  is  always  a  well-typed  LF  object  (point  1  in 
tli(’  th(H)r(uns  above)  not  every  well-typed  LF  object  is  the  representation  of  an  expression,  predicate 
or  (h'rivation  even  though  it  has  the  appropriate  type.  The  reason  is  that  the  LF  representation 
function  only  produces  objects  that  do  not  contain  y5-redices  (canonical  objects).  In  fact  the 
ad(‘(juacv  j)roofs  in  [5,  13]  introduce  first  the  notion  of  canonical  LF  objects  and  then  prove  that 
is  a  l)i  j(‘ctive  function.  Those  results  can  be  used  to  obtain  proofs  of  the  above  adequacy  theorems 
by  introducing  a  normalization  judgment  that  can  be  shown  to  preserve  /3-equivalence. 
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all^i  (Aei  :  exp. 

all  {Xeo  :  exp. 

all  (Aes  :  exp. 

=>  (=  ei(+  62  63)) 

(=  (“  ei  63)  62)))) 

(Aei  :  exp 
all^i  {X(2  :  exp. 

all  (Ae3  :  exp. 

=>  (=  ei(+  62  63)) 

(=  (“  ei  63)  62))) 

(Af2  •  exp 
all_i  (Aes  :  exp. 

=>  (=  ei(+  62  63)) 

(=  (-  ei  63)  62)) 

(A63  :  exp 

(impl^i  (=  61  (+  62  63)) 

(=  (-  ei  63)  62) 

(Au  :  pf  (=  61  (+  62  63))  . 

(=tr  (-  61  63) 

(+  62  63)  63) 

^2 

(-congr  61 

(+  €2  63) 

es 

es 

u 

(=id  63)) 

(=tr  (-  (+  62  63)  63) 

(+  62  (-  63  63)) 

62 

(+-assoc  62 
63 
63) 

(=tr  (+  62  (-  63  63)) 
(+  62  0) 


62 

(+congr  62 
62 

(“  63  63) 

0 

(=id  62) 
(+inv  63)) 
(+id  62))))))))) 


Figure  12:  LF  representation  of  the  proof  shown  in  Figure  3. 
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5  The  Implicit  LF  Representation 

The  LF  representation  and  type-checking  algorithm  presented  in  the  previous  section  are  adequate 
for  the  representation  and  validation  of  proofs.  However  the  proof  representations  are  unnecessarily 
large.  This  is  apparent  in  the  proof  representation  of  Figure  12,  where,  for  example,  the  expression 
€2  occurs  23  times,  and  it  becomes  even  more  pronounced  in  larger  examples.  The  redundancy 
in  the  LF  representation  is  no  larger  than  the  redundancy  in  the  original  proof  of  Figure  3,  but 
nevertheless  we  would  prefer  to  manipulate  smaller  proofs. 

The  size  of  proofs,  in  general,  is  an  important  factor  in  any  application  that  manipulates  proofs 
explicitly,  but  the  redundancy  of  representation  in  particular,  has  important  consequences  for 
the  efficiency  of  proof  checking.  Consider  an  instance  of  a  Proof-Carrying  Code  where  the  code 
consumer  desires  to  check  that  the  untrusted  safety  proof  (for  exaiiijilo.  the  one  from  Figure  12) 
enclosed  with  the  code  proves  a  certain  predicate.  In  such  a  situation  every  subterm  of  the  proof 
representation  must  be  type-checked.  This  means  that  each  of  the  23  oc'currences  of  the  LF  term  62 
must  be  type-checked  separately  Moreover,  following  each  of  the  type-clu^cking  operations  the  term 
must  be  compared  with  the  instance  of  itself  contained  in  the  predicate'  to  be  proven,  to  ensure  that 
every  subderivation  proves  the  desired  predicate.  Therefore  the  redundancy  in  the  representation 
increases  the  amount  of  required  checks  and  therefore  can  lead  to  inefficient  proof  validation. 

We  address  the  problem  of  proof  size  at  its  source.  We  eliminate'  the  redundancy  in  the  repre¬ 
sentation  by  omitting  redundant  copies  and  maintaining  only  one  cojiy.  It  is  a  good  idea  to  try  to 
preserve  only  the  copy  contained  in  the  proved  predicate,  if  such  a  copy  exists.  This  is  motivated 
by  the  fact  that  the  proved  predicate,  and  all  of  its  subterms,  can  be  trusted  to  be  well- formed. 

During  type-checking  we  reconstruct  the  missing  copies  from  the  subterms  of  the  proven  predi¬ 
cate.  This  addresses  not  only  the  proof  size  problem  but  also  reduces  drastically  the  effort  involved 
in  proof  validation.  The  reason  is  that  the  reconstruction  algorithm  is  designed  so  that  whenever  a 
missing  copy  of  a  subterm  is  reconstructed  we  know  that  the  resulting  term  is  well-typed,  without 
having  to  typecheck  it.  Similarly  the  equivalence  check  does  not  normally  have  to  be  performed 
because  of  the  properties  of  reconstruction. 

The  algorithm  that  we  present  in  this  section  is  able  to  analyze  the  term  shown  in  Figure  13 
and  check  that  it  represents  the  implicit  form  of  a  valid  proof  of  the  predicate  shown  in  Figure  3. 
Compare  this  implicit  representation  with  the  full  LF  representation  of  a  proof  of  the  same  predicate 
shown  in  Figure  12. 

Before  we  plunge  into  the  formal  details  of  the  type  reconstruction  we  show  how  the  algorithm 
works  on  a  simple  example.  For  the  purpose  of  this  example  consider  a  new  kind  of  object,  called  a 
placeholder,  written  as  *  and  marking  a  missing  LF  object.  Consider  now  the  proof  of  the  predicate 
P  D  P  A  P.  If  we  apply  the  LF  representation  algorithm  presented  in  the  previous  section,  we 
obtain: 

impl-i  (and  ^P~^  ^P~^)  {Xuipf  ^P^.and_i  ^P~^  ^P~^  u  u)  (1) 

The  redundancy  of  the  representation  is  manifested  through  the  presence  of  6  copies  of  the  term 
which  can  be  a  sizeable  term  in  general.  It  is  easy  to  check  the  type  of  the  representation 
above  to  be  pf  (impl  '"P"'  (and  ^P"^  We  are  going  to  replace  all  occurrences  of  ^P"*  in  the 

representation  of  the  proof  by  placeholders  and  then  show  how  type-reconstruction  works  for  the 
resulting  object. 

The  implicit  representation  of  the  considered  proof  is: 

impl_i  *1  *2  (Aifc:*3.and_i  *4  *5  w  u)  (2) 
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all_i  * 

(A^i  :  * 
all_i  * 

(Ae2  :  * 

all_i  * 

(Aes  :  * 

*  * 

(Xu  :  *. 

(=tr  *  *  * 

(-congr  *  *  *  ♦ 


(=id  *)) 

(=tr  *  *  * 

(+-assoc  *  ♦  *) 

(=tr  *  ♦  * 

(+congr  *  *  ♦  * 
(=id  *) 
(+inv  *)) 
(+id  *))))))))) 


Figure  13:  Implicit  LF  representation  of  the  proof  shown  in  Figure  3. 

where  are  5  placeholders,  which  are  labelled  for  demonstration  purposes.  We  claim  that  the 
above  LF  term  captures  the  essence  of  the  proof.  The  remaining  parts  of  the  proof  representation 
can  be  recovered  while  verifying  that  the  the  term  has  type  pf  (impl  (and  rp~\^y 

Typechecking  starts  by  recognizing  the  top-level  constructor  The  type  of  the  entire 

term,  pf  (impl  ^P~'  (and  '"P"'  '”P^)),  is  “matched"  against  the  result  type  of  the  impl_i  constant, 
as  given  by  the  signature  S.  The  result  of  this  matching  is  an  instantiation  for  placeholders  1  and 
2  and  a  residual  type-checking  constraint  for  the  explicit  argument  of  impl_i: 

*1  =  ^P^ 

*2  =  aiid  '~P~^  '"P"^ 

h  (Aix:*3.and_i  *4  *5  u  w)  :  pf  ‘"P"'  ->  pf  (and  '"P"^  rpn^ 

Now  we  continue  with  the  remaining  type-checking  constraint.  From  its  desired  type  we  imme¬ 
diately  obtain  the  value  of  placeholder  3  and  a  typing  constraint  for  the  body: 

*3  =  pf  '”P~' 

u  :  pf  '”P'^  h  and_i  *4  *5  w  w  :  pf  (and  '”P"'  '”P"') 

Now  we  notice  that  and_i  is  the  top-level  constant  and  by  matching  its  result  type  declared  in 
the  signature  with  the  goal  type  we  get  the  instantiation  for  placeholders  4  and  5  and  two  residual 
typing  constraints: 

*4  =  ^P^ 

*5  = 

u  :  pf  ‘”P"'  u  :  pf  '"P"' 
u  :  pf  ‘~P~'  h  u  :  pf  '~P"' 

The  remaining  two  typechecking  constraints  are  solved  by  the  variable  typechecking  rule,  and 
this  concludes  typechecking  the  entire  proof.  We  reconstructed  the  full  representation  of  the  proof 
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by  instantiating  all  the  placeholders  with  well-typed  LF  objects.  We  know  that  these  instantiations 
are  well-typed  because  they  are  ultimately  extracted  from  the  original  constraint  type,  which  is 
assumed  to  contain  only  well-typed  subterms. 

Starting  with  the  next  section  we  define  a  type-system,  called  LF^,  which  is  very  similar  to  the 
LF  type-system  but  allows  for  placeholders.  However,  the  LF^  type-system  is  not  very  useful  for 
typechecking  or  type  reconstruction.  For  this  purpose  we  describe  in  Section  6  a  reconstruction 
algorithm  for  LFy. 

5.1  The  LF/  Type-System 

We  extend  th('  .syntax  of  LF  objects  with  placeholders,  written  *.  An  object  is  fully  reconstructed, 
or  fully  exj)licit.  wh(m  it  is  placeholder-free.  We  write  PF(M)  to  denote  this  property.  We  extend 
this  notation  to  tyi)(‘  environments  and  we  write  PF(r)  to  denote  that  all  the  types  assigned  in  P  to 
variables  an'  placeholder-free.  We  also  introduce  the  implicitly  typed  abstraction,  written  Ax.M, 
at  the  level  of  obj('cts. 

We  call  tli(‘  n'sulting  system  of  terms  and  types  implicit  LF  and  we  refer  to  it  by  LF^.  The 
typing  ruk's  of  LF,  are  an  extension  of  the  LF  typing  rules  with  two  new  typing  rules  for  dealing 
with  implicit  abstraction  and  placeholders,  and  one  new  /3-equivalence  rule  dealing  with  implicit 
abstraction.  Th('S('  additions  are  shown  in  Figure  14.  The  LF^  typing  judgment  is  written  T  f  M  : 
A. 

Objects  : 

E(c)  =  A  T{x)  =  A  TfMiA  A=^B  PF(A) 

FPcrA  T^xiA  tTmTb 

r,x:AfM:B  F.xiAfMrB 

F  P  Xx.M  :  Ux:A,B  T  P  Xx:AM  :  Ux:A,B 

rfM:Ux:A,B  FPWrA  PF{A)  FF  M  :Ux:A.B  FFNiA  PF(A) 
r\^M  N:  [N/x]B  F  M  *  :  [N/x]B 

Equivalence  : 

{Xx:AM)N  ^^\Nfx\M  1^x~M)N^^\NIA^ 

Figure  14:  The  LF^-  type-system  as  an  extension  of  LF. 

Note  that  according  to  the  LF^  type-system  placeholders  cannot  occur  on  a  function  position. 
This  restriction  is  consistent  with  the  previous  example  and  is  essential  for  the  correctness  of  the 
reconstruction  algorithm.  Also  note  that  we  restrict  the  types  to  be  placeholder-free  in  several 
rules.  This  restriction  simplifies  greatly  the  proofs  of  soundness  and  does  not  seem  to  get  in  the 
way  when  validating  implicit  representation  of  proofs. 

A  quick  analysis  of  the  LF^  type-system  reveals  that  it  is  not  very  useful  for  type-checking  or 
type-inference.  The  main  reason  is  that  typechecking  an  application  involves  “guessing”  appropriate 
A  and  N,  The  type  A  can  sometimes  be  recovered  from  the  type  of  the  application  head,  but  the 
term  N  in  an  application  to  a  placeholder  cannot  be  found  easily  in  general.  This  is  not  a  problem 
for  us  because  we  are  going  to  use  the  LF^  type-system  just  as  a  step  in  proving  the  correctness 
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of  the  type-reconstruction  algorithm  presented  in  the  next  section,  and  not  as  the  basis  for  an 
implementation  of  a  typechecking  algorithm. 

The  only  property  of  interest  of  the  LF^  type-system  is  that  once  we  have  a  typing  derivation 
we  can  reconstruct  the  object  involved  and  a  corresponding  LF  typing-derivation.  To  make  this 
more  precise  we  introduce  the  notation  M  M'  to  denote  that  M'  is  a  fully-reconstructed  version 
of  the  implicit  object  M  (i.e.,  PF(M')).  This  means  that  all  the  placeholders  in  M  have  been 
replaced  by  fully-explicit  LF  objects  and  similarly  all  the  implicit  abstractions  have  been  replaced 
by  explicit  abstractions.  Note  that  the  reconstruction  relation  is  not  a  function  as  there  might  be 
many  reconstructions  of  a  given  implicit  object  or  type. 

Theorem  5.1  Soundness  of  LF^  typing  Ifr\^M:A  and  PF(r),  PF(^),  then  there  exists  M' 
such  that  M  M'  and  F  1^^  M'  :  A. 

The  proof  of  Theorem  5.1  is  shown  in  Section  8.6. 

To  give  an  example  of  a  situation  where  Theorem  5.1  is  used  consider  that  we  have  constructed — 
using  the  algorithm  presented  in  the  next  section  for  example — a  typing  derivation  •  F  M  :  pf  “"P"* 
for  some  predicate  P  and  a  term  M  possibly  containing  placeholders.  Then  Theorem  5.1  says 
that  there  exists  an  LF  term  M'  such  that  •  M'  :  pf  ^P”^,  or  equivalently  that  there  exists  a 
proof  of  the  predicate  P.  Theorem  5.1  reduces  the  problem  of  checking  a  proof  to  finding  a  LF^ 
typing-derivation  for  the  implicit  proof-representation  M. 

6  An  Algorithm  for  LF^  Type  Reconstruction 

The  LFi  type-system  presented  in  the  previous  section  has  the  benefit  that  can  deal  with  implicit 
LF  terms.  However  this  type-system  does  not  immediately  suggest  a  type-checking  algorithm,  as 
explained  before.  We  show  in  this  section  an  algorithm  that  can  be  used  to  typecheck  LF^  terms, 
or  more  precisely  to  reconstruct  and  typecheck  LF^  terms. 

We  start  with  introducing  some  notation  and  then  we  present  the  algorithm  at  an  abstract 
level,  in  terms  of  inference  rules,  and  we  deal  with  actual  implementation  issues  in  Section  10. 

6.1  Notation 

In  addition  to  the  placeholder  constants  introduced  in  the  previous  section  we  introduce  a  new  brand 
of  variables.  These  variables  play  similar  role  to  that  of  placeholders  in  that  they  stand  for  missing 
terms.  We  shall  use  the  letters  x  and  y  to  denote  traditional  LF  variables  and  the  letter  u  to  denote 
a  placeholder  variable.  Also,  we  use  the  letter  A  to  denote  a  type  environment  containing  only  type 
assignments  for  placeholder  variables.  The  letter  F  will  denote  type  environments  containing  any 
kind  of  variables.  In  the  special  case  when  an  LF  object  M  does  not  contain  placeholder  variables 
we  write  PVF(M).  Note  that  placeholder  variables  always  occur  free. 

We  extend  this  notation  and  we  write  PVF(F(FV(M)))  to  mean  that  the  types  associated  by 
F  to  the  free  variables  of  M  do  not  contain  placeholder  variables. 

The  main  operation  on  placeholder  variables  is  substitution  with  LF  terms.  We  define  the 
syntactic  class  of  substitutions  as  follows: 

$  .  I  u  ^  M  Substitutions 

We  denote  by  ^(M)  the  term  obtained  by  performing  the  substitution  on  M.  We  write 
Dom(^)  to  refer  to  the  set  of  placeholder  variables  on  which  ^  is  defined.  We  write  PF(^^)  to 
mean  that  all  the  terms  substituted  for  placeholder  variables  are  placeholder-free. 
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We  write  ^^[5  to  denote  the  substitution  obtained  from  by  restricting  it  to  the  set  of  place¬ 
holder  variables  S. 

One  of  the  key  operations  performed  by  the  reconstruction  algorithm  is  to  compute  substitutions 
through  unification  of  terms  or  types.  For  a  more  precise  presentation  we  use  two  flavors  of 
unification  shown  below  as  unification  of  terms.  The  same  notation  is  used  for  expressing  unification 
of  types. 

M  ^  ^  Atomic  Unification 

M  »  M'  =>  Unification 

The  last  syntactic  construct  that  we  introduce  is  a  list  of  type  reconstruction  constraints  defined 
as  follows: 

C  ::=  •  \  C,M:A  |  C.A^aB 

The  reconstruction  algorithm  is  described  by  the  two  unification  judgments  introduced  above 
and  three  additional  mutually  recursive  judgments  shown  below: 

T  f  M  :  A=>  Main  reconstruction  judgment 

T  f  M  ^  {A  ;  C  ;  B)  Collect  constraints 
r  F  C  Solve  constraints 

We  continue  now  with  the  definition  of  the  five  judgments  introduced  above.  The  collection  of 
these  inference  rules  constitute  an  abstract  description  of  the  reconstruction  algorithm. 

6.2  Collecting  Typechecking  Constraints  :  F  F  M  (A  ;  C  ;  S) 

This  judgment  is  used  for  atomic  objects  M,  which  are  constants  or  variables  applied  to  zero  or 
more  canonical  objects.  A  canonical  object  is  a  sequence  of  abstractions  with  an  atomic  body.  The 
object  M  is  scanned  to  find  the  application  head,  whose  type  is  read  from  the  signature  S  or  from 
the  variable  type  environment  F.  Then  all  arguments  are  collected  in  the  residual  type  constraint 
list  C  together  with  their  type.  Placeholder  variables  are  introduced  for  each  placeholder  arguments 
and  are  collected  in  A  with  their  type.  The  resulting  type  B  is  the  type  of  the  whole  application 
and  might  contain  placeholder  variables  from  A.  Similarly,  the  types  in  the  constraint  list  C  might 
contain  placeholders  variables  from  A.  Note  that  no  placeholders  can  occur  in  types  because  of  the 
side-condition  on  the  rule  pertaining  to  the  application  to  a  placeholder. 


r  c  ;  S(c))  r  a;  =»(•;•  ;  r(a;)) 

r  F  M  =»  (A  ;  (7  ;  Ux-.A.B)  x  e  FV{S)  D  (PF(Ar)  and  PVF(A)  and  PVF(r(FV(JV)))) 

TfMN^{A;C,N:A-,  [N/x]B) 

TfM^{A-,C-,Ux:A.B)  .  ,  ^ 

,r  ^ - T-x — — — 7::; — F — t-tttt  is  a  new  placeholder  variable 

rFM*=>(A,'u:A;C;  [u/x]B)  ^ 

In  the  next  section  we  describe  how  the  list  of  constraints  is  solved.  The  main  reason  we  sep¬ 
arate  the  tasks  of  collecting  constraints  and  solving  them  is  to  allow  an  arbitrary  order  in  solving 
the  constraints.  We  discovered  that  this  can  greatly  increase  the  effectiveness  of  the  reconstruc¬ 
tion  algorithm,  with  the  benefit  that  proof  representations  can  be  made  smaller  by  making  more 
subterms  implicit. 
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The  restriction  in  the  explicit  application  rule  ensures  that  the  resulting  type  [iV/xjB  does  not 
have  placeholders,  provided  that  B  does  not  have  placeholders.  This  restriction  simplifies  the  proof 
of  correctness  of  the  reconstruction  and  is  also  required  in  order  to  use  the  LF^  typing  judgments, 
which  are  defined  only  on  types  without  placeholders. 

6.3  Solving  Residual  Constraints:  F  F  C 

This  judgment  describes  the  process  of  solving  all  the  type-checking  constraints  in  a  list  C  in  an 
arbitrary  order.  To  accommodate  arbitrary  orders  we  introduce  the  constraint  reordering  rule. 
Note  that  in  any  particular  case  a  given  order  is  used  so  that  the  reconstruction  is  more  effective. 
However,  for  the  purpose  of  the  reconstruction  algorithm  we  do  not  care  about  the  particular  order 
used. 


rfCi,C2,C3=^^ 
rF-=>-  rfC2,CuCz=^^ 

r  F  M  ;  ^  ^'(r)  F  ^(C)  ^  ^(F)  F  ^(C) 

rfC,M:A^'<b'o'^  r  F  C,  A  Wo  B  o 

6.4  Type  Reconstruction  for  Objects:  F  F  M  :  ^ 

This  is  the  base  judgment  of  the  type-reconstruction  algorithm.  The  term  M  can  contain  variables 
(but  no  placeholder  variables)  that  are  defined  in  F  and  constants  that  are  defined  in  S.  M 
can  also  contain  placeholders  and  implicit  abstractions.  However,  the  restriction  is  that  the  type 
environment  F  and  the  type  A  do  not  contain  placeholders.  This  is  again  required  in  order  to 
relate  the  type  reconstruction  judgment  to  the  LFj  typing  judgment  and  has  the  beneficial  efiect 
of  simplifying  the  proof  of  correctness. 

Recall  that  a  canonical  LFq  object  is  either  an  abstraction  with  a  canonical  body  or  an  atomic 
object.  The  type-checking  judgment  deals  directly  with  abstractions  and  invokes  the  constraint 
collecting  and  solving  judgments  for  atomic  objects. 

F,a;:^FM:B=^- 

FFAa;.M:na::AB=:>- 

Note  that  the  implicit  abstraction  recovers  the  argument  type  from  the  goal  type,  which  must 
be  a  type  abstraction.  Note  also  that  no  reconstruction  is  allowed  under  abstraction  (the  returned 
substitution  must  be  empty).  This  restriction  does  not  harm  in  any  way  the  usefulness  of  the 
reconstruction  algorithm  for  first-order  logic  proofs  but  simplifies  the  correctness  arguments  greatly 
by  eliminating  worries  about  the  returned  substitution  containing  the  bound  variable  x. 

In  the  case  of  a  constant,  a  variable  or  an  application  the  typing  judgment  first  collects  type 
reconstruction  constraints  that  are  then  solved  in  an  arbitrary  order. 

F  F  M  =>  (A  ;  C  ;  B) _ F,  A  F  C,A  B  ^ _ Dom{A)  C  Dom{'^>)  M  is  not  an  ab- 

F  F  M  :  A  ^  I  Dom{T)  straction 

Note  in  the  previous  rule  that  it  is  required  that  the  substitution  returned  be  defined  on  all 
placeholder  variables  introduced  by  the  current  collecting  operation.  In  this  respect  the  presented 
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type  reconstruction  algorithm  is  simpler,  and  potentially  less  powerful,  than  constraint  based  al¬ 
gorithms  that  allow  reconstruction  constraints  to  persist  unsolved  beyond  the  place  where  they 
were  introduced.  However,  this  restriction  does  not  seem  to  limit  the  power  of  the  algorithm  for 
reconstructing  first-order  proof  representation  but  on  the  other  hand  eliminates  the  need  for  all  the 
machinery  for  managing  persistent  constraints. 

Note  also  that  the  reconstruction  algorithm  does  not  check  explicitly  that  the  returned  substi¬ 
tution  is  well-typed.  However,  this  property  holds  because  of  the  design  of  the  unification,  which 
we  present  next. 


6,5  Unification:  M  M'  and  M  ^  ^  ^ 

The  purpose  of  unification  is  to  check  the  equivalence  of  two  objects  or  two  types.  As  a  result,  the 
unification  constructs  a  substitution  of  terms  for  placeholder  variables.  Both  terms  being  checked 
might  contain  implicit  abstractions  and  might  not  be  in  canonical  form,  but  they  cannot  contain 
placeholders. 

The  main  restriction  of  the  unification  that  we  present  here  is  that  is  does  not  try  to  unify 
terms  where  the  placeholder  variable  is  the  head  of  an  application.  In  such  a  case  the  resulting 
substitution  would  not  be  uniquely  defined  and  thus  we  prefer  to  avoid  it.  However,  this  restriction 
does  not  seem  to  harm  the  power  of  the  reconstruction  of  first-order  logic  proofs.  In  order  to  express 
this  restriction  we  use  two  flavors  of  uniflcation:  atomic  and  normal.  Only  the  atomic  unification 
can  be  used  for  the  head  of  an  application  and  we  restrict  it  so  that  a  placeholder  variable  is  not 
instantiated  by  an  atomic  uniflcation.  The  uniflcation  judgments  are  presented  below. 

Atomic  Unification 

C  c  — ^  *  OC  OC  — * 


M  Wa  M'  ^(N)  ^  ^{N')  ^ 

M  N  M'  N'  ^ O 'ilf 

Normal  Unification 


[Nn/Xn]  ■  ■  ■  [Ni/xi]M 
(Arci _ \Xn-M)  Ni  .  .  .  Nji  ftin  M'  => 


M  ss  M'  =»  • 
Xx.M  «  Xx.M'  ■ 


M  ggg  M'  ^ 

M  ^  M’  ^  ^ 


u  ^  FV(M) 
u  ^  M  u  i—  M 

The  side  condition  on  the  instantiation  rule  is  required  for  correctness.  Checking  this  condition 
requires  scanning  the  object  M  that  is  used  to  replace  the  placeholder  denoted  by  the  placeholder 
variable  u.  We  would  very  much  want  to  avoid  this  check.  Recall  that  we  had  two  arguments  in 
favor  of  the  implicit  representation:  smaller  representation  size  and  faster  checking  based  on  the 
fact  that  the  reconstructed  objects,  such  as  M  here,  do  not  require  checking  because  they  are  part 
of  the  trusted  type.  As  expressed  by  the  unification  judgment  the  reconstructed  fragments  do  not 
require  checking  but  they  require  scanning.  However,  in  many  cases  that  occur  in  checking  proofs 
of  first-order  logics  the  occurs  check  is  not  necessary.  We  view  the  removal  of  the  occurs  check  as 
an  optimization  and  we  discuss  it  in  Section  9.3. 
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6.6  Why  does  type  reconstruction  work? 

The  five  reconstruction  judgments  described  in  the  previous  sections  can  be  used  directly  as  a  type 
reconstruction  algorithm.  The  process  of  reconstructing  and  typechecking  an  object  M  proceeds 
as  follows: 

•  If  M  is  an  abstraction  then  use  the  abstraction  rule  and  continue  with  the  reconstruction  of 
the  body. 

•  Otlierwise,  M  must  be  a  variable  or  a  constant  applied  to  zero  or  more  arguments.  Use  the 
collecting  judgment  to  scan  the  arguments  and  replace  the  implicit  ones  with  placeholder 
variables  and  collect  the  explicit  arguments  in  a  list  of  type  reconstruction  constraints.  Add 
to  the  list  of  constraints  the  unification  of  the  required  type  for  the  application  and  the  type 
computed  based  on  the  type  of  the  application  head  and  arguments. 

•  Solve  the  list  of  constraints  in  a  convenient  order.  As  a  result,  return  an  instantiation  for 
SOUK'  placeholder  variables. 

•  \  erify  that  all  local  placeholders  have  an  instantiation. 

Th(‘  above  procedure  can  be  implemented  directly  as  described  by  the  inference  rule  describing 
th(‘  rcH'onstruction  judgments.  If  all  we  are  concerned  is  validating  implicit  representation  of  first- 
on  l('r  proof  we  can  further  simplify  and  optimize  the  algorithm,  as  shown  in  Section  9.3.  Before  we 
discuss  these  optimization  we  prove  the  correctness  of  the  reconstruction  algorithm.  Corollary  6.1 
r('lat(\s  the  reconstruction  judgments  to  the  implicit  typing  judgment.  This  is  a  suflficient  correctness 
criterion  for  checking  proofs  because  of  Theorem  5.1,  which  in  turn  relates  the  LF^  typing  judgment 
to  th('  LF  typing  judgment  shown  to  be  adequate. 

Corollary  6.1  (Correctness  of  proof  reconstruction)  If  M  is  an  LFi  object  such  that 
PVF(M)  and  •  F  M  :  pf  •  then  •  F  M  :  pf 

Unfortunately,  the  proof  of  Corollary  6.1  is  nowhere  as  simple  as  its  statement  and  therefore 
we  devote  the  entire  next  section  to  it.  Section  8  is  necessarily  very  technical  but  the  reader  can 
safely  skip  Section  8  on  the  first  reading  and  go  to  Section  9.3  where  several  optimizations  of  type 
reconstruction  are  discussed. 
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7  Algorithms  for  Implicit  Representation 

Section  6  presents  a  type  reconstruction  algorithm  that  is  able  to  typecheck  LF  terms  containing 
placeholders.  It  is  obvious  that  not  all  subterms  can  be  reconstructed  by  our  algorithm  and  therefore 
not  all  implicit  representations  of  a  term  can  be  typechecked  using  it.  In  this  section  we  define 
three  algorithms  that  can  be  used  to  eliminate  redundant  copies  of  subterms  in  such  a  way  that 
the  resulting  implicit  representation  can  be  typechecked  using  our  reconstruction  algorithm. 

In  order  to  simplify  the  discussion  of  the  representation  algorithms  we  fix  the  order  of  constraint 
solving  such  that  the  type  unification  is  always  performed  first  followed  by  the  typing  constraints 
in  the  reversed  order  of  their  collection.  Formally,  we  restrict  our  attention  to  an  implementation 
of  reconstruction  where  the  constraint  reordering  rule  is  not  used.  This  order  is  suited  for  the  vast 
majority  of  reconstruction  tasks.  We  shall  discuss  the  few  exceptions  at  the  end  of  this  section. 

We  present  the  implicit  representation  algorithms  as  erasure  procedures,  converting  the  full 
LF  representations  to  implicit  representations.  The  simplest  erasure  algorithms  presented  below 
translate  easily  to  representation  function  defined  as  mapj)ings  from  proofs  to  LF^  terms,  following 
the  model  of  the  full  LF  representation  function  prescmted  in  Section  3. 

We  consider  three  algorithms  with  varying  complexity  and  effectiveness.  The  output  of  each  of 
these  algorithms,  as  well  as  the  fully-explicit  representation,  are  equally  well  suited  for  typechecking 
using  the  reconstruction  algorithm  presented  in  Section  6.  The  only  difference  is  the  size  of  the 
proof  representation  and  the  running  time  of  the  reconstruction.  The  quantitative  analysis  of  the 
erasure  eff’ectiveness  is  presented  in  Section  II. 

The  first  algorithm  is  completely  local  in  the  sense  that  the  erasure  of  a  term  does  not  depend 
on  the  context  where  the  term  occurs.  Then  we  improve  the  representation  by  recording  a  one- 
bit  information  about  the  enclosing  context.  This  is  equivalent  to  having  two  erasure  algorithms 
working  in  tandem.  The  last  algorithm  is  fully  global  and  it  attempts  to  optimize  the  size  of  the 
representation  by  analyzing  the  entire  enclosing  context. 

We  conclude  this  section  with  a  brief  discussion  of  the  situations  where  each  of  the  presented 
algorithms  has  practical  value  and  when  a  combination  of  them  makes  sense. 

7.1  A  Local  Algorithm 

We  start  with  a  local  erasure  algorithm  that  defines  the  erasure  of  an  LF  term  independently  of  its 
surrounding  context.  This  algorithm  can  be  viewed  as  an  alternative  mapping  from  proofs  to  LF* 
terms,  to  be  used  instead  of  the  full  representation  function  shown  in  Section  3. 

The  local  erasure  algorithm  is  specified  as  a  set  of  representation  recipes,  one  for  each  constant  in 
the  signature.  We  write  R{c)  to  denote  the  representation  recipe  of  the  constant  c.  A  representation 
recipe  is  a  sequence  of  representation  characters,  each  corresponding  to  an  argument  to  which  the 
constant  is  applied.  The  length  of  the  representation  recipe  is  dictated  by  the  number  of  arguments 
that  the  constant  can  take.  For  the  local  algorithm  we  consider  only  two  representation  characters,  * 
and  e.  Each  argument  that  corresponds  to  an  *  representation  character  is  replaced  by  a  placeholder 
and  each  argument  that  corresponds  to  an  e  is  replaced  with  its  implicit  representation. 

For  example,  the  representation  recipe  associated  with  the  constant  and_i  is  *  *  e  e,  writ¬ 
ten  i?(and_i)  =  **ee.  This  means  that  the  implicit  representation  of  the  full  LF  term 
and_i  Mi  M2  M3  M4  is  and^i  *  *  M3  M4,  where  M3  and  M4  are  the  implicit  representations 
of  M3  and  M4  respectively. 

Before  we  consider  the  details  of  computing  representation  recipes  we  show  the  definition  of 
the  local  implicit  representation  as  a  function  M  A  M'.  We  shall  use  the  auxiliary  function 
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M  A  M'  +  R  to  say  that  the  implicit  representation  of  the  application  M  is  M'  and  the  recipe 
for  the  remaining  arguments  of  M  is  R.  We  also  use  the  notation  e'^  to  denote  a  fully-explicit 
representation  recipe,  which  is  used  for  the  applications  whose  head  is  a  variable. 

mAm^  m  a  +  i? 

Xx:A.M  A  Xx.M^  M  A  M' 

_  MiAm[  +  ^R  MiAM[+eR  M2  A 

c  A  c  +  Ric)  X  A  x  +  e^  Ml  M2  A  M[^  +  R  Mi  M2  A  +  i? 

Note  that  as  part  of  the  local  erasure,  the  type  of  bound  variables  is  removed  in  addition  to 
those  terms  specified  by  the  representation  recipes. 

The  only  missing  detail  of  the  local  erasure  algorithm  is  the  representation  recipe  function. 
Recall  that  during  the  type  reconstruction  the  constraint  solving  judgment  must  instantiate  all  local 
placeholder  variables.  Recall  also  that  we  are  considering  an  implementation  of  type  reconstruction 
that  always  solves  first  the  unification  judgment  from  a  constraint  list.  For  the  local  erasure 
algorithm,  we  impose  the  simple  restriction  that  all  the  local  placeholder  variables  are  instantiated 
while  solving  the  unification  constraint.  In  this  is  true  then,  whenever  a  typing  judgment  is  invoked 
as  part  of  constraint  solving,  the  type  does  not  contain  placeholder  variables  or  placeholders.  This 
invariant  is  clearly  established  initially  because  the  top-level  type  cannot  contain  free  variables  and 
is  preserved  by  constraint  solving  because  the  unification  is  always  performed  first. 

In  order  to  maintain  the  above  mentioned  restriction  we  must  only  introduce  placeholder  vari¬ 
ables  that  are  going  to  be  instantiated  while  unifying  the  application  result  type  with  another 
type  without  placeholder  variables.  This  determines  which  arguments  in  an  application  can  be 
placeholders. 

If  we  view  the  constants  in  the  signature  as  representations  of  proof  rules,  then  the  local  erasure 
algorithm  says  that  in  each  rule  we  must  explicitly  specify  at  least  the  instantiations  of  logical 
variables  that  could  not  be  recovered  from  the  conclusion  of  the  rule. 

Before  we  give  a  general  recipe  function  we  discuss  the  cases  of  several  constants.  Consider  first 
the  constant  +  with  the  following  type: 

-f-  :  exp  — )►  exp  — >  exp 

It  is  obvious  that  no  placeholder  variable  can  be  instantiated  as  part  of  the  unification  of  the 
result  type  (exp)  with  another  type.  Therefore,  no  implicit  arguments  are  allowed  for  the  constant 
+.  This  is  denoted  by  the  representation  recipe  R{+)  =  ee.  Following  the  same  line  of  reasoning 
we  infer  that  the  representation  of  expressions  and  predicates  must  be  fully-explicit. 

The  next  constant  we  consider  is  and_i  with  the  type: 

and^i  :  np:pred.nr  :pred.pf  p  ^  pf  r  — )•  pf  (andp  r) 

If  we  unify  the  type  pf  (and  Up  Ur)  with  another  type,  and  if  the  unification  succeeds,  then  we 
obtain  instantiations  for  Up  and  for  Ur  and  for  nothing  else.  This  suggests  that  the  only  arguments 
of  and_i  that  can  be  implicit  are  the  first  two.  This  is  denoted  by  the  recipe  i?(and_i)  =  *  *  e  e. 

Next  we  consider  the  case  of  the  constant  and-er  with  the  type: 

and_er  :  np:pred.nr  :pred.pf  (andp  r)  pf  r 
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For  the  same  reasons  as  above  we  see  that  only  the  argument  r  can  be  instantiated  by  solving  the 
unification  constraint,  hence  the  representation  recipe  i2(and_er)  =  e  *  e  e.  Note  that  even  when  the 
argument  p  could  be  recovered  by  type  inference  on  the  third  argument,  the  local  erasure  algorithm 
rec|uires  it  to  be  explicit.  It  is  in  cases  like  this  where  more  sophisticated  erasure  algorithms,  such 
as  the  ones  showed  next,  achieve  smaller  representations. 

W('  conclude  our  examples  with  a  slightly  trickier  case.  Consider  the  constant  all_e  with  the 
tvi)e: 

all_e  :  lip: exp  pred.IIerexp.pf  (all  p)  pf  (p  e) 

In  this  case  the  type  pf  {up  Ue)  does  not  unify  with  any  another  type  because  the  placeholder 
varial)l('  Up  is  in  an  application  head  position.  Therefore  at  least  the  predicate  p  must  be  given 
('xi)licitly  in  order  to  perform  the  unification.  If  this  is  the  case,  we  consider  unifying  the  type 
pf  (P  //, )  for  some  P.  We  cannot  assume  that  Ue  is  instantiated  by  this  unification  because,  for 
('xaiiipl(\  lie  might  not  occur  at  all  in  the  normal  form  of  {P  Ue)-  Because  of  this,  the  expression  e 
must  also  given  explicitly.  This  justifies  the  all-explicit  representation  recipe  i?(all>.e)  =  eee.  Note 
that  ill  a  signature  representing  first-order  logic  there  are  only  few  cases  where  similar  situations 
o(’cur.  namely  the  constants  related  to  universal  and  existential  quantification. 

\\V  could  continue  the  case  analysis  for  all  the  constants  from  S.  Instead,  we  prefer  to  develop 
a  giUKu  al  algorithm  for  computing  the  representation  recipes. 

As  \vv  have  seen  in  the  informal  computation  of  representation  recipes,  it  is  important  to  know 
th('  s('t  of  i^laceholder  variables  that  are  certainly  instantiated  during  the  unification  of  a  term.  For 
this  purpose  we  define  a  function  Inst  that  computes  the  set  of  ‘^nstantiable”  variables  of  a  term. 

Tli(’  definition  of  Inst  follows  the  structure  of  the  unification  judgment  and  has  an  atomic  and 
a  normal  variant.  We  write  Inst{M)  —  S  to  mean  that  the  variables  in  S  are  certainly  instantiated 
by  th<'  successful  normal  unification  of  M  with  an  LF  term  without  placeholder  variables.  The 
atomic  variant  of  the  instantiation  function  is  written  Insta{M)  =  S'  +  /3,  where  /3  is  an  output 
parameter  specifying  whether  the  head  of  M  is  a  placeholder  variable.  These  judgments  are  defined 
by  the  following  rules: 


Insta{M)  =  S  +  ^  Insta{Mi)  =  0  -h  true 
Inst{Xx:A.M)  —  0  Inst{u)  =  {n}  Inst{M)  =  S  Insta{Mi  M2)  =  0  +  true 

Insta{Mi)  —  Si  +  false  Inst  {M2)  =  S2 

Insta{u)  =  0  +  true  Insta{c)  —  0  +  false  Insta{Mi  M2)  =  Si  U  S2  4-  false 

Note  in  the  above  rules  that  no  variable  is  instantiated  during  the  unification  of  an  abstraction. 
Also,  if  the  head  of  an  application  is  a  variable  then  the  atomic  instantiation  function  returns 
(3  —  true  and,  as  in  the  case  of  all_e  discussed  above,  we  must  assume  that  no  variable  is 
instantiated  as  part  of  the  unification.  The  precise  relation  between  the  instantiation  judgments 
and  the  unification  is  described  by  the  following  theorem: 

Theorem  7.1  N  andPVF(^o)  and'PY¥{N)  then  Insta{M)  C 

This  theorem  says  that  all  the  variables  in  Insta{M)  that  are  not  already  instantiated  (by 
are  instantiated  during  unification  with  a  type  without  placeholder  variables.  The  theorem  has  an 
easy  proof  by  induction  on  the  structure  of  M. 

It  is  convenient  to  define  the  complementary  function  NonInst{A)  —  FV(A)\/n5^a(A),  to  denote 
the  set  of  variables  that  are  not  necessarily  instantiated  as  part  of  the  unification  of  A, 
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Next  we  define  the  representation  recipe  function  using  the  helper  judgment  Ra{^)  =  r  +  S, 
where  ^  is  a  type,  r  is  partial  a  representation  recipe  and  S'  is  a  set  of  placeholder  variables  that 
are  guaranteed  to  be  instantiated  while  unifying  the  result  part  of  A.  The  representation  recipe  of 
a  constant  c  is  computed  based  on  its  type  i;(c)  as  follows: 

R{c)=r  if  RAi^{c))=r  +  S 
The  Ra  judgment  is  defined  by  the  following  rules: 

Ra{[u/x]B)  =  r  +  S  u  e  S  Ra{[u/x]B)  =  r  +  S  ti  ^  S 
RA(n.x:A.B)  ==  +  S  Ra{TIx:A,B)  =  e7‘  A-  S 


A  is  atomic 
Ra{A)  =  •  +  Inst{A) 

The  Ra  judgment  scans  the  type  of  a  constant,  starting  from  tlu'  result  type.  It  computes  the 
set  of  instantiable  variables  of  the  result  type  and  then  works  backward  adding  to  the  representation 
recipe  a  *  character  if  the  corresponding  argument  is  instantiated  or  an  e  character  otherwise. 

This  completes  the  definition  of  the  representation  recipe  function  and  with  it  the  description 
of  the  local  erasure  algorithm.  We  present  next  a  more  sophisticated  erasure  algorithm  that  works 
in  a  similar  way. 

7.2  The  One-bit  Global  Algorithm 

The  local  erasure  algorithm  presented  above  has  the  advantage  of  simplicity  and  context  inde¬ 
pendence.  However,  there  are  practical  cases  when  its  result  is  not  satisfactory.  Consider  the 
fully-explicit  term  representing  a  proof  of  Pi  D  P2  '> 

impl^i  Pi  P2  {\x:pf  Fi.impl_e  Pi  P2  Di  x)  :  pf  (impl  Pi  P2) 

assuming  that  Pi  :  pf  (impl  Pi  P2)  for  some  predicate  representations  Pi  and  P2.  The  local 
representation  recipe  for  the  two  proof  constants  involved  (defined  in  Figure  8  on  page  9)  are 
P(impl_i)  =  *  *  e  and  P(impl_e)  =  e  *  e  e.  Therefore  the  local  erasure  of  the  above  term  is: 

impl_i  *  *  (Air.impl_e  Pi  ^  D[  x)  :  pf  (impl  Pi  P2) 

assuming  that  D[  is  the  local  erasure  of  Pi.  We  immediately  see  that  the  first  argument  to  impl_e 
could  be  reconstructed  from  the  context  in  which  it  appears,  for  example  from  the  fact  that  a 
representation  of  its  proof  is  x  of  type  pf  Pi.  This  example  is  very  simple  and  the  potential  savings 
are  small.  However,  similar  situations  occur  whenever  there  are  proof  rules  for  which  some  of  the 
logical  parameters  cannot  be  recovered  from  the  conclusion  alone  but  from  the  surrounding  context. 
This  is  the  case  with  conjunction  and  implication  elimination  rules  and  many  arithmetic  rules  such 
as  the  transitivity  of  equality. 

The  one-bit  global  erasure  algorithm  uses  only  one  bit  of  information  about  the  context  or  more 
precisely  about  the  circumstances  in  which  the  type  reconstruction  will  be  invoked  on  the  term. 
This  bit  of  information  says  whether,  at  the  time  of  type  reconstruction,  the  type  can  contain 
placeholder  variables  or  not.  If  the  type  cannot  contain  variables  we  say  that  the  term  must  be 
represented  for  typechecking.  Otherwise  we  say  that  it  must  be  represented  for  type  inference,  and 
in  such  a  way  that  type  reconstruction  on  that  term  alone  must  succeed  in  finding  an  instantiation 
for  all  placeholder  variables  that  appear  in  the  type. 
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We  express  the  one-bit  global  erasure  algorithm  in  terms  of  representation  recipes,  in  a  similar 
manner  as  the  local  algorithm.  We  replace  the  e  representation  character  with  two  separate  char¬ 
acters  Cc  (for  checking)  and  €{  (for  inference).  Due  to  the  fact  that  now  the  erasure  function  uses 
one-bit  of  global  information  (whether  it  is  checking  or  inference)  we  change  the  erasure  function 

to  M  ^  M'  where  p  can  be  either  c  or  i  The  only  erasure  rules  that  are  changed  are  those  for 
constants  and  for  explicit  application: 


M[+ecR  M2  4  Ml  ^Mj  +  ejR  M2  4  _ 

MiM2^M[M2  +  R  MiM2^M(M^  +  i?  c^c  +  Rp{c) 

The  one-bit  representation  recipes  now  determine  not  only  whether  an  argument  must  be  im¬ 
plicit  or  not,  but  also  whether  the  explicit  arguments  must  be  represented  for  checking  or  for 
inference.  At  this  point  we  have  reduced  the  erasure  to  the  static  computation  of  the  representa¬ 
tion  recipes  Ri  and  Rc  for  each  constant  in  the  signature.  These  functions  are  computed,  as  in  the 
local  case,  using  an  auxiliary  judgment  i?^(A)  =  r  +  Si  +  Se-  In  addition  to  the  set  of  variables 
Si  that  are  instantiated  by  constraint  solving,  the  new  judgment  also  contains  a  set  of  placeholder 
variables  Se  that  must  be  explicit.  This  judgment  is  defined  by  the  following  rules: 

_ A  is  atomic _  _ A  is  atomic _ 

-^a(^)  “  *  +  Inst  [A)  -h  NonInst{A)  i?^(A)  =  •  +  0  +  NonInst{A) 


RF^{[uIx]B)  ~  r  -\-  Si  +  Se  u  e  Si 
R^j^{Ilx:A,B)  =^^r-^Si  +  Se 

R\{[u/x]B)=r  +  Si  +  Se  u^Si  Inst{A)  <Z  SiU  Se 
lij^{Jlx:A.B)  =  Cc  r  -f-  4-  5e  U  {NonInst{A)\Si) 

R\{[u/x]B)  =  r-^Si  +  Se  u^Si  InstiA)  gSiUSe 
R^^{Ux:A.B)  ^eiV  +  SiU  {Inst{A)\Se)  +  SeU  {NonInst{A)\Si) 

The  definition  of  R^  deserves  some  explanations.  First,  recall  the  assumption  that  the  con¬ 
straints  are  solved  in  the  reverse  order  of  introduction,  starting  with  the  unification  constraint.  In 
the  case  of  checking,  the  unification  is  with  a  type  without  placeholder  variables.  The  result  is  an 
instantiation  for  all  instantiable  placeholder  variables  (therefore  Si  =  Inst  {A))  provided  that  all 
non-instantiable  variables  (collected  in  Se)  are  explicit.  This  justifies  the  rule  for  R\{A)  when  A  is 
atomic.  In  the  case  of  inference  the  same  unification  happens  but  this  time  with  a  type  that  might 
contain  placeholder  variables.  We  have  to  assume  conservatively  that  no  placeholder  variable  is  in¬ 
stantiated  to  a  fully-explicit  term,  hence  Si  =  0.  However,  we  also  require  that  all  non-instantiable 
variables  are  explicit  as  in  the  case  of  checking.  This  explains  the  rule  for  R\{A)  when  A  is  atomic. 
In  case  of  RF^iJlx:  A.B)^  because  of  the  constraint  solving  order  we  first  deal  with  the  arguments 
corresponding  to  B.  If  u  is  instantiated  after  dealing  with  B  then  it  can  be  left  implicit,  hence  the 
rule  for  *  r.  Otherwise,  the  argument  corresponding  to  u  must  be  left  explicit  and  depending  on 
whether  the  variables  of  A  are  all  instantiated  at  this  point  we  decide  whether  to  use  checking  or 
inference  on  it.  The  set  Se  is  collecting  the  set  of  placeholder  variables  that  cannot  be  instantiated 
because  they  occur  in  function  position  in  some  type.  Note  that  the  sets  Si  and  Se  are  always 
disjoint. 
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A  case  where  Se  is  non-empty  and  is  essential  for  the  correctness  of  the  erasure  algorithm  is  for 
all_e  of  type: 

all_e  :  lip: exp  pred.ne:exp.pf  (all  p)--^  pf  {p  e) 

In  this  case  p  G  Noninst  {pf  {p  e))  but  p  G  Inst  {pf  (all  p)).  If  we  did  not  maintain  the  list 
Se  we  could  have  the  impression  that  p  can  be  reconstructed  by  type  inference  on  the  term  of  type 
pf  (all  p)  without  noticing  that  the  unification  constraint  would  have  failed  earlier  because  of  a 
placeholder  occurring  in  an  application  head  position. 

Using  the  function  we  can  define  the  representation  recipes  as  in  the  local  algorithm: 

Rp{c)  =r  if  i?^(S(c))  -  r  + 

In  the  tabl(‘  Ix'low  we  show  examples  of  representation  recipes  as  produced  by  the  local  algorithm 
and  the  oiK'-bit  rc'presentation  algorithm.  We  notice  that  in  the  case  of  +,  and  similarly  for  all 
expression  and  pn'dicate  constants,  all  arguments  must  be  explicit  in  both  the  local  and  the  one- 
bit  representation  recipes.  Also,  in  such  cases,  the  inference  recipe  and  should  never  be  required 
during  erasun\  The  next  four  cases  shown  in  the  table  are  examples  where  the  one-bit  global 
algorithm  is  abh’  to  remove  more  arguments  than  the  local  erasure  algorithm. 


c 

Ric) 

Rc{c) 

Ri{c) 

+ 

ee 

and„el 

*  ee 

*  *  e^ 

*  *  e^ 

and_er 

e*  e 

*  *  e^ 

*  *  e^ 

impl_e 

e  *  ee 

*  *  e^  e^ 

*  *  ei 

=  tr 

*  e  *  e  e 

*  *  *  ec  e^ 

*  *  *  ei  ei 

-hcom 

*  * 

*  * 

all.e 

eee 

Table  2:  Examples  of  representation  recipes  computed  by  the  local  and  one-bit  global  algorithms. 

In  order  to  analyze  the  relation  between  the  local  and  the  one-bit  recipes  we  remark  that  the 
local  representation  function  is  a  special  case  of  the  one-bit  representation  recipes.  The  main 
difference  is  that  the  set  Se  in  the  local  recipe  function  is  always  the  negation  of  the  set  Si  with 
respect  to  the  universe  of  variables.  This  only  needs  to  be  enforced  in  the  rule  for  in  the  one-bit 
function  in  order  to  recover  the  local  recipe  function. 

With  the  above  remark  we  see  that  the  size  of  set  Si  in  the  local  recipe  function  never  increases 
beyond  the  initial  size  established  for  the  result  type.  And  as  the  size  of  Si  determines  the  maximum 
number  of  implicit  arguments  we  conclude  that  the  local  erasure  algorithm  will  always  remove  fewer 
arguments  that  the  one-bit  global  algorithm  for  every  particular  application.  This  conclusion  is 
supported  by  the  examples  shown  in  Table  2. 

Furthermore  we  notice  in  Table  2  that  Rc{c)  has  more  implicit  arguments  than  Ri{c)  and  also 
more  ei  characters  corresponding  to  the  explicit  arguments.  This  can  be  explained  informally  by 
remembering  that  there  are  additional  constraints  when  representing  a  term  for  inference  instead 
of  just  checking.  In  the  case  of  the  representation  for  inference,  the  term  must  contain  enough 
subterms  to  allow  the  reconstruction  of  its  type,  while  in  the  case  of  checking  more  subterms  can 
be  omitted  and  later  reconstructed  from  the  fully-explicit  type. 

We  can  characterize  the  one-bit  global  erasure  algorithm  as  eliminating  some  explicit  arguments 
remaining  after  the  local  erasure  and  redistributing  the  information  required  for  their  reconstruction 
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to  the  subterms  corresponding  to  sibling  arguments,  by  marking  them  for  inference.  The  additional 
information  required  for  inference  is  more  apparent  at  the  leaves  of  the  proof  tree.  Here  there  are 
no  siblings  to  offload  to  information  and  hence  the  inference  erasure  is  not  able  to  erase  any 
subterms  while  the  checking  erasure  can  remove  all  of  them.  This  is  illustrated  by  the  case  of  +com. 
Even  though  the  cost  in  the  one-bit  representation  is  pushed  towards  the  leaves,  the  resulting 
representation  is  in  general  smaller  than  the  local  representation  because  part  of  the  size  of  the 
erased  argument  is  reconstructed  from  the  structure  of  the  proof  of  sibling  arguments,  and  only  a 
small  part  from  explicit  arguments  at  the  leaves. 

7.3  The  Global  Algorithm 

The  local  erasure  algorithm  is  able  to  recover  some  arguments  of  the  rei)resentation  of  a  proof- 
rule  instance  from  the  conclusion  of  the  proof  rule.  Then  in  the  one-bit  algorithm  we  increase 
the  reconstruction  power  by  recovering  additional  arguments  from  the  structure  of  some  of  the 
hypotheses  of  the  proof-rule.  In  this  section  we  present  an  even  better  algorithm  that  recovers 
additional  arguments  by  examining  the  entire  context  in  which  a  proof-rule  is  used.  Also,  the  global 
erasure  algorithm  attempts  to  overcome  another  limitation  of  the  previous  algorithms,  namely  the 
loss  of  information  due  to  the  static  conservative  approximation  of  non-instantiable  variables.  The 
global  algorithm  considers  each  constant  with  its  actual  parameters  and  can  therefore  minimize  the 
set  of  non-instantiable  variables. 

The  basic  idea  of  the  global  algorithm  is  to  start  by  assuming  that  all  arguments  of  the  repre¬ 
sentation  of  a  proof-rule  instance  are  implicit  and  then  simulate  type  reconstruction.  Whenever  an 
argument  cannot  be  reconstructed  it  is  made  explicit  and  its  implicit  representation  is  made  part 
of  the  final  representation. 

Because  the  global  erasure  algorithm  works  by  simulating  type  reconstruction,  it  has  the  same 
overall  structure.  Unfortunately  there  are  enough  minor  variations  to  require  a  new  implementation. 
This  make  the  global  erasure  algorithm  expensive  to  implement. 

The  first  change  we  have  to  make  is  to  the  unification  judgments  to  consider  the  case  of  a 
placeholder  variable  that  is  the  head  of  an  application.  In  this  case  the  placeholder  variable  must 
be  instantiated  with  the  term  from  the  full  representation  that  it  replaces.  For  this  to  be  possible 
the  unification  judgment  must  take  a  parameter  containing  the  instantiations  for  all  placeholder 
variables  that  would  produce  the  original  fully-explicit  term.  Also  the  unification  must  return,  in 
addition  to  the  usual  substitution,  another  substitution,  called  the  explicit  substitution,  containing 
instantiations  for  the  non-instantiable  variables.  We  use  the  following  notation  to  denote  the  new 
variant  of  unification  b  A  J3  ^  Similarly  we  add  a  new  substitution  argument 

and  an  additional  substitution  result  to  the  main  typing  judgment.  The  resulting  judgment  is 
written  r  +  ^obM:A^^^  +  To  this  we  add  one  additional  result  M',  the  resulting  implicit 
representation  of  M,  and  we  write  the  resulting  judgment  in  functional  style  GErase^T^  Af,  A)  ~ 
(^,  The  global  erasure  algorithm  is  given  informally  in  Figure  15  and  a  step-by-step 

explanation  is  made  below.  A  formal  description  of  the  algorithm  would  follow  the  structure  of  the 
type  reconstruction  judgments. 

In  the  case  of  an  abstraction  the  erasure  is  done  recursively  on  the  body  of  the  abstraction  and 
the  type  of  the  bound  variable  is  omitted  from  the  resulting  representation. 

In  the  case  of  a  constant  application  there  is  an  opportunity  to  leave  some  of  the  arguments 
implicit.  We  start  in  step  2(a)  by  introducing  a  placeholder  variable  for  each  argument,  trying 
therefore  to  maximize  the  number  of  implicit  terms.  In  step  2(b)  we  record  the  original  values  of 
the  newly  introduced  placeholder  variables  in  the  substitution  ^^o* 
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GErase{r,  4'0)  M,  ^4)  = 


1.  If  M  =  Xx'.Ai.Mi  and  A  =  'n.x:Ai.A2  with  GErase{T,x  :  Ai,’^o,Mi,A2)  =  then 

the  result  is  {■,'^e,Xx.M[) 

2.  If  M  =  c  M\ . . .  Mfi  and'E{c)  =^Ilx\:Ai - nrc„:^n-^n+i  then 

(a)  Let  A  =  ui  :  Ai,U2  :  [ui/xiJAg, . . .  :  [un-i/xn-i]- ■  ■  and 

(b)  Let  ^0  =  Ml, . . .  4—  Mn,  and 

(c)  Let  ^>0  ^  ~o  [Un/Xn]  •  •  •  [uilxi]An+i  ^ 

3.  iei  A  =  ^  o  ^'e(A) 


I  If^  =  ;  then  return  with  5  ^e|L>om(r)  5  ^  •  •  •  ^n)  '^here 

if  Ui  E  Dom{<^e) 

^  \  *  otherwise 

5.  (a)  Let  A  =  A'^Uk  :  A'j^f  nnd 

(b)  Let  G^;ra5e((r,A'),^^o,^oK),^fc)  = 

(c)  Let  ^  M'j^]  o  o  and 

(d)  Let  ^  o  and 

(e)  Let  A  =  A'^  and 

(f)  Go  to  step  3 


Figure  15:  The  informal  description  of  the  global  erasure  algorithm. 


The  purpose  of  the  remaining  steps  is  to  build  the  substitution  giving  an  instantiation  for 
those  arguments  that  cannot  possibly  be  implicit.  Recall  that  constraint  solving  is  done  in  reverse 
order,  starting  with  the  unification  constraint.  We  start  therefore  with  the  unification  and  in  step 
2(c)  we  compute  both  the  set  of  variables  that  must  be  explicit  in  order  for  the  unification  to 
succeed  (^g)  and  the  set  of  variables  successfully  instantiated  by  the  unification. 

Then  in  step  3  we  remove  these  variables  from  A.  If  no  variables  remain,  then  we  conclude 
that  all  placeholder  variables  introduced  in  step  2(a)  can  be  either  recovered  or  must  be  explicit 
in  order  for  the  constraint  list  to  be  solvable.  We  return  with  an  implicit  representation  of  M'  as 
dictated  by  ^g- 

If  there  are  placeholder  variables  left  in  A  then  at  least  the  last  one  must  be  explicit.  If  this  were 
not  the  case  we  would  have  no  possibility  of  recovering  it  by  solving  the  remaining  constraints.  In 
order  to  compute  its  implicit  representation  we  recursively  invoke  the  global  erasure  on  the  original 
value  of  the  placeholder  variable  ^^o(^A:)*  The  resulting  implicit  representation  is  added  to  ^^g  such 
that  it  can  be  inserted  in  the  final  result  in  step  4.  However,  during  the  computation  of  the  global 
erasure  of  ^^o(^/c)  w®  might  have  instantiated  further  variables  (^^')  and  found  variables  that  must 
be  explicit  (^^g).  These  variables  are  removed  from  A  in  step  3  and  we  cycle  until  all  the  variables 
in  A  are  dealt  with. 

The  global  erasure  algorithm  achieves  an  optimal  representation  given  a  specific  constraint 
solving  order.  This  is  the  case  because,  by  design,  it  starts  with  all  arguments  implicit  and  it  only 
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reverts  an  argument  to  explicit  status  when  the  reconstruction  would  not  work  otherwise. 

7.4  Discussion 

In  all  three  erasure  algorithms  we  have  assumed  a  specific  order  of  constraint  solving.  In  our  exper¬ 
iments  this  fixed  order  performed  surprisingly  well.  However,  in  selected  cases  the  representation 
can  be  made  even  smaller  if  a  different  order  is  adopted.  The  largest  benefit  can  be  achieved  if  we 
allow  a  different  reconstruction  order  for  each  application  instance. 

We  have  not  tried  this  approach  but  instead  we  have  selected  a  few  constants  for  which  a 
non-default  order  has  the  potential  of  decreasing  the  size  of  the  representation.  An  example  is  the 
constant  all_e  where  it  is  better  to  typecheck  the  constraint  corresponding  to  pf  (all  p),  with  the 
hope  of  recovering  ,p,  before  solving  the  unification  constraint  on  pf  {p  e),  which  invariably  fails  if 
p  is  not  instantiated.  This  approach  produced  such  minor  improvements  that  we  did  not  consider 
it  further. 

Despite  its  limited  knowledge  of  the  context,  the  local  erasure  algorithm  produces  implicit 
terms  that  are  close  to  optimal  for  most  logic  proof  rules  and  it  might  be  a  good  practical  choice 
in  situations  where  absolute  optimality  is  not  required.  In  situations  where  the  size  of  the  proof  or 
the  its  validation  time  is  crucial  we  can  use  one  of  the  global  algorithms. 

As  we  mentioned  before,  the  global  erasure  algorithm  is  optimal  for  a  given  reconstruction  order. 
However  it  requires  as  one  of  its  inputs  the  whole  LF  term,  which  might  be  very  large.  Another 
disadvantage  surfaces  in  the  cases  where  the  proof  is  build  gradually  from  small  pieces  at  a  time, 
as  is  the  case  in  a  theorem  prover  that  outputs  a  proof  representation.  These  small  pieces  cannot 
be  optimized  until  the  whole  proof  is  constructed. 

We  show  in  Section  11  that  we  din  not  noticed  major  improvements  in  the  size  of  the  rep¬ 
resentation  produced  by  the  global  algorithm  when  compared  to  the  one-bit  algorithm.  This,  in 
conjunction  with  the  disadvantages  of  the  global  erasure  algorithm,  makes  us  conclude  that  it  is 
not  worth  using,  or  in  other  words  that  the  simpler  one-bit  algorithm  achieves  near  optimal  results. 

We  believe  that  the  practical  way  to  build  implicit  representations  of  proofs  is  to  use  the 
local  algorithm  for  maintaining  small  intermediary  fragments  of  proofs.  When  the  whole  proof  is 
assembled  we  can  apply  the  one-bit  global  erasure  algorithm  to  it.  The  result  will  be  the  same  as 
if  we  started  from  the  fully-explicit  representation  but  without  the  expense  of  building  the  large 
intermediary  proof  object.  Another  benefit  is  that  the  overall  running  time  is  usually  smaller  when 
running  the  erasure  algorithms  in  sequence  because  the  more  primitive  the  algorithm  the  smaller 
the  cost  of  erasing  one  subterm. 

The  correctness  criterion  for  an  erasure  algorithm  is  that  the  type  reconstruction  algorithm 
succeeds  on  the  resulting  representation.  We  did  not  state  formal  correctness  results  for  the  erasure 
algorithm  presented  in  this  section  for  two  main  reasons.  One  is  that  we  motivated  each  design 
choice  in  the  erasure  algorithms  with  respect  to  the  type  reconstruction  algorithm.  Also,  for 
practical  reasons,  the  correctness  of  the  erasure  algorithm  is  not  crucial.  Its  result  can  always  be 
validated  by  running  the  type  reconstruction  algorithm. 
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8  The  Correctness  Proof  of  Type  Reconstruction 


In  this  section  we  prove  that  the  reconstruction  algorithm  presented  in  the  previous  section  is 
adequate  for  checking  the  validity  of  proofs.  One  of  the  advantages  of  developing  the  proof  checking 
algorithm  as  a  variation  on  LF  typechecking  is  that  we  have  a  well-understood  formal  framework 
that  can  be  used  for  the  succinct  expression  of  the  correctness  criteria  and  also  for  proving  them. 

We  want  to  stress  that  the  proof  of  correctness  is  not  just  an  exercise  in  type-theoretic  proofs. 
Besides  the  obvious  purpose  of  ensuring  the  correctness  of  the  type  reconstruction  algorithm — 
which  is  not  obvious  by  inspection  only — the  correctness  proof  also  constitutes  a  thorough  analysis 
of  the  strengths  limitations  of  our  algorithm. 

The  algorithm  that  we  presented  in  the  previous  section  is  limited  by  the  side-conditions  present 
in  some  of  the  rules,  most  notably  the  collection  of  explicit  parameters,  the  typing  of  abstractions 
and  the  instantiation  rule.  The  correctness  proof  can  serve  as  a  reference  documenting  the  need  for 
every  such  side-condition.  In  many  practical  cases  the  reconstruction  is  used  in  circumstances  when 
some  of  the  side-conditions  do  not  need  to  be  enforced.  These  circumstances  can  be  discovered 
only  after  a  deep  understanding  of  the  purpose  of  the  side  conditions  in  the  correctness  proof. 

In  Section  10  we  show  how  we  can  significantly  improve  the  performance  of  the  reconstruction 
algorithm  by  removing  some  of  the  side  conditions  in  the  special  case  when  we  are  checking  first- 
order  logic  proofs. 

The  rest  of  this  section  is  very  technical  and  can  be  skipped  on  first  reading.  The  only  reference 
back  to  the  material  in  the  rest  of  the  section  is  to  justify  some  of  the  optimizations  that  we 
implemented  for  the  reconstruction. 

8.1  Notation  and  Conventions 

We  write  ^^(r)  to  denote  the  result  of  applying  the  substitution  ^  to  a  type  environment  F.  The 
resulting  type  environment  is  defined  on  Dom{'if{r))  =  Dom{T)\Dom{'^f)  as  follows: 

^{r){x)  =  ^{T{x))  \/x  E  Dom{T)\Dom{<if) 

Note  that  the  type  declarations  for  the  placeholder  variables  defined  by  the  substitution  are 
removed  from  the  resulting  type  environment. 

We  write  F  h  ^  to  denote  that  the  substitution  is  well-typed  according  to  a  type  environment 
F,  using  the  LF^  typing  rules.  As  a  general  note,  our  reference  typing  system  is  LF^.  Formally, 

F  h  ^  iff  Vu  E  Dom{^)  then  u  E  Dom{r)  and  ^(F)  1^  ^(u)  :  ^(F(u)) 

In  order  to  simplify  the  presentation  of  the  correctness  proofs  in  this  section  we  make  the 
convention  that  all  the  types  involved  are  placeholder-free.  This  applies  to  types  given  as  part 
of  the  theorem  hypothesis  or  types  mentioned  in  the  conclusion  of  helper  lemmas  and  theorems. 
Whenever  new  types  are  created  we  shall  check  this  property  but  we  do  not  express  it  explicitly  in 
the  statements  of  the  theorems.  Because  of  this  convention  we  can  use  freely  the  LF^  typing  rules 
without  checking  that  the  PF  side-conditions  hold. 

In  order  to  keep  the  presentation  focused  we  have  segregated  a  number  of  helper  lemmas  in 
Section  8.7  at  the  end  of  this  section. 


31 


8.2  Correctness  of  the  Type  Reconstruction  Judgment 

The  type  reconstruction  algorithm  is  expressed  as  five  mutually  recursive  judgments.  Not  sur¬ 
prisingly  the  correctness  proof  of  the  reconstruction  algorithm  consists  of  five  mutually  dependent 
correctness  proofs  for  the  constituent  judgments.  These  proofs  are  by  induction  on  the  structure 
of  the  reconstruction  judgments.  Occasionally,  a  proof  invokes  the  theorem  for  a  related  judgment, 
in  the  same  way  as  the  corresponding  judgment  invokes  a  related  judgment.  For  the  five  proofs 
at  hand  the  chain  of  theorem  invocations  is  circular  but  the  derivations  involved  are  structurally 
smaller,  therefore  the  induction  is  well-founded. 

We  start  with  the  correctness  theorem  about  the  main  reconstruction  judgment.  We  cannot 
prove  the  Corollary  6.1  directly.  Instead  we  have  to  strengthen  the  statement  of  the  theorem  so 
that  the  induction  goes  through.  In  particular  we  have  to  allow  for  arbitrary  typing  environments 
and  types.  Note  that  there  might  be  placeholder  variables  in  F  and  A  but  no  placeholders.  The 
correctness  theorem  is  stated  formally  bellow: 

Theorem  8.1  (Correctness  of  the  Type  Reconstruction)  IfT  and  A  are  a  type  environment 
and  a  type  respectively  such  that  PF(r)  and  PF(^)  and  T  }r  A  :  Type  and  M  is  a  term  such  that 
PVF(M)  andifrfM:A^<It  then 

•  r  h  and 

•  PF(^),  and 

•  ^^(r)  \^M:^{A), 

Prom  the  Theorem  8.1  we  can  immediately  prove  the  Corollary  6.1  for  the  empty  type  environ¬ 
ment  and  the  empty  substitution,  if  we  note  that  PF(pf  by  the  definition  of  the  representation 
function. 

Proof:  (of  Theorem  8.1)  The  proof  is  by  induction  on  the  structure  of  the  derivation  V  r.T  f  M  : 
A  ^  There  are  two  cases,  depending  on  the  last  rule  used  in  V. 

Case:  If  M  is  an  abstraction: 

Vi 

T,x:AfM:B^- 
^  ~  Tf  Xx.M  :Ux:A.B  ^  ‘ 

It  is  obvious  that  the  empty  substitution  is  well- typed  and  placeholder- free.  Because  PF(r)  and 
PF{Ilx:A.B)  it  follows  that  we  can  apply  the  induction  hypothesis  on  Vi  and  infer  that  P,  a;  :  A  F 
M  :  B,  Therefore  we  can  also  infer  that  F  F  Xx.M  :  JlxiA.B,  which  is  the  desired  conclusion. 
Case:  If  M  is  not  an  abstraction: 

Vi  V2 

FFM=>(A;C;P)  F,  A  F  C,  A  ^  ^  Dom{A)  C  Dom{^) 

We  follow  the  sequence  of  deduction  steps  shown  below: 

1.  F  F  A  :  Type  (hypothesis), 

2.  PF(F)  and  PF(A)  and  PVF(M)  (hypothesis), 

3.  Using  Theorem  8.4  on  V2  we  infer  that 


4.  For  all  N  :  A'  from  C  there  exist  and  ^2  such  that  ^i(r,  A)  f  ^'i(iV)  :  ^i(A')  =>  ^2 

5.  With  2,  4  we  apply  Theorem  8.5  on  T>i  (with  A'  =  0)  and  infer  that 

6.  r,  A  F  B  :  Type,  and 

7.  PF(A),  and 

8.  PF(B),  and 

9.  For  all  N  :  A'  in  C  we  have  PF(A')  and  PVF(A/')  and  F,  A  P  A' :  Type 

10.  From  1  we  infer  that  F,  A  P  j4  :  Type. 

11.  With  2,  6,  7,  8,  9  and  10  we  apply  Theorem  8.6  on  T>2  and  infer  that 

12.  F,  A  h  4^,  and 

13.  ^(B),  and 

14.  PF(«'),  and 

15.  For  all  N  :  A'  in  C  we  have  4'(F,  A)  P  N  :  4'(>1').  Also  using  Lemma  8.20  with  Dom{A)  C 
Bom('F)  we  infer  that  ^(F)  P  N  :  ’F(A'). 

16.  With  9,  12,  14,  15  we  apply  Theorem  8.7  and  infer  that 

17.  ^'(F)  P  M  :  ^(B) 

18.  Because  all  placeholder  variables  from  A  are  new,  they  cannot  occur  in  F  or  in  B.  Therefore 
^(Bom(F))  =  ’I'|£)oTO(r)  (P)  ^■ud  ^'(B)  =  '3^|/)om(r)  i^)-  Therefore  we  get  one  of  the  desired 
conclusions. 

19.  With  12  and  using  Lemma  8.20  we  prove  that  F  h  4'|£)o„j(r).  Also  from  14  we  can  easily 
prove  that  PF(^'|£,o„,(r) ). 

□ 

8.3  Correctness  of  Unification 

The  most  important  judgments  for  the  type  reconstruction  algorithm  presented  in  the  previous 
section  are  the  unification  judgments.  Their  properties  are  crucial  for  the  correctness  of  the  re¬ 
construction  and  their  implementation  determine  the  performance  of  the  reconstruction.  The  key 
property  of  the  unification  judgments  is  that  the  resulting  substitution  preserves  the  types  of  the 
placeholder  variables,  and  as  a  consequence  the  algorithm  does  not  need  to  typecheck  the  substi¬ 
tution. 

The  properties  of  interest  of  the  unification  judgments  are  expressed  in  Theorem  8.2.  The  first 
two  parts  of  the  theorem  deal  with  atomic  unification  of  types  and  objects  respectively.  The  last 
part  deals  with  normal  unification  of  objects. 

Theorem  8.2  (Correctness  of  Unification)  All  the  types  mentioned  in  the  statement  below  are 
assumed  to  be  placeholder- free. 
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(a)  If  Ai  A2  ^  such  that  T  f  Ai  :  Ki  and  T  f  A2  :  K2  then 

•  r  h  and 

•  PF(^)j  and 

•  =0  ^(^2);  and 

•  ^{Ki)=0<i^{K2) 

(b)  If  M\  AI)  =^>  and  PF(Mi)  and  PF(M2)  such  that  F  F  Mi  :  Ai  and  F  F  M2  :  A2  then 

•  F  h  arid 

•  PF(^^).  and 

•  ^^(A/|)  =  ,,  4^(M2),  and 

•  q/(.4i)=, 

//Ml  il/2  a/icf  PF(Mi)  and  PF(M2)  5?ic/i  that  F  F  Mi  :  A  and  F  M2  :  A  then 

•  r  F  and 

•  PF('^).  and 

•  0/(4/,)  0/(M2) 

The  coinpli('at(Hl  statement  above  is  required  in  order  to  prove  the  theorem  by  induction.  All 
the  actual  usc^s  of  tlu'  Theorem  8.2  are  in  the  form  of  a  much  simpler  corollary  shown  below.  The 
corollary  follows  immediately  from  the  case  (a)  of  Theorem  8.2  by  taking  Ki  =  K2  —  Type. 

Corollary  8.3  If  A\  A2  ^  "it  such  that  F  F  Ai  :  Type  and  F  F  A2  :  Type  then 

1.  F  h  and 

2.  PF(^),  and 

3.  ^^(Ai)  >F(A2). 


Proof:  (of  Theorem  8.2)  The  proof  is  by  induction  on  the  structure  of  the  unification  derivations. 
We  only  show  here  the  cases  for  the  unification  of  objects  (cases  b  and  c).  The  proof  for  atomic 
unification  of  types  follows  the  same  patterns. 

Case: 


The  empty  substitution  is  well-typed  in  any  environment  and  is  also  placeholder-free.  By  hypothesis 
we  know  that  F  F  c  :  Ai  and  F  F  c  :  A2.  From  Lemma  8.14  we  conclude  that  Ai  A2.  The  rest 
of  the  conclusion  follows  immediately. 

Case: 


V  = 


Jb 


Again,  the  typing  condition  on  the  resulting  substitution  is  vacuously  true.  By  hypothesis  we  know 
that  r  a;  :  Ai  and  F  F  a;  :  A2.  Prom  Lemma  8.14  we  infer  that  Ai  A2,  which  concludes  the 
proof  of  this  case. 
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Case: 


[Nlx]M  ^aM' 

{Xx.M)  N^aM' 

For  the  purpose  of  the  correctness  proof  we  only  consider  the  /^-reduction  case  with  only  one 
argument  (n  =  1).  The  general  case  is  proved  in  a  similar  way. 

By  hypothesis  we  have  that  F  f  (Xx.M)  N  :  Ai.  Prom  Lemma  8.14  we  infer  that  F  F  Xx.M  : 
n.r  :  A.B  and  F  F  iV  :  ^  and  [Nlx]B  Ai-  Because  PF((Aa;.M)  N)  we  infer  that  PF(Aa;.M) 
and  PF(A'’).  Therefore  PF([A^/a:]M).  Now  we  can  use  the  Lemma  8.15  to  infer  that  F  \N/x]M  : 
[.V/.r]Zl  and  therefore  F  F  [N/x^M  :  Ai.  Now  we  apply  the  induction  hypothesis  on  V\  and  infer 
that  F  H  'F  and  ^(^i)  ^(^2)  a-nd  that  PF(^). 

We  also  conclude  from  the  induction  hypothesis  that  '^{[N/x]M)  But  '^{[N/x]M)  = 

[^'(.V )/./•] 4'(M)  '^{(Xx.M)N),  which  completes  the  proof  of  this  case. 

Case: 

X>i  7X2 

M  M'  ^  «'(iV)  w  '^{N')  =>  '9' 

M  N  ^aM'  N' 

We  hdlow  a  sequence  of  deductions: 

1.  From  T  M  N  :  Ai  (hypothesis)  and  Lemma  8.14  we  get 

2.  F  F  M  :  Ux-.A.B,  and 

8.  F  F  AT  :  A,  and 

4.  [N/x]B  =0  Ai. 

5.  From  F  F  M'  N' :  A2  (hypothesis)  and  Lemma  8.14  we  get 
C.  FFM'  :  lix-.A'.B',  and 

7.  F  F  iV'  :  A\  and 

8.  [iV7a:].B' A2. 

9.  Using  2  and  6  we  apply  the  induction  hypothesis  on  Vi.  We  conclude: 

10.  F  F  and 

11.  PF(^),  and 

12.  ^(na::A.5)  ^(Ux-.A'.B’),  and 

13.  ^(M)  =0  ^(M'). 

14.  With  3,  10  and  11  we  use  Corollary  8.17  and  deduce  that  ^'(F)  F  ^!{N)  :  ^'(A). 

15.  With  7,  10  and  11  we  use  Corollary  8.17  and  deduce  that  ^(F)  F  '^{N')  :  ^(A'),  and  using 
12  we  also  deduce  that  ^(F)  F  ^{N')  :  ^(A). 

16.  Prom  11  we  infer  that  PF(^(7V’))  and  PF(^(Ar')).  This  together  with  14  and  15  let  us  apply 
the  induction  hypothesis  on  F>2-  We  deduce  that: 
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17.  ^^(r)  h  and 

18.  PF(^^').  and 

19.  ^'(^(AT))  ^r'(^(7V')). 

20.  From  10,  11,  17  and  18  with  Lemma  8.19  we  get  the  first  part  of  the  conclusion:  F  H  o 
and  PF(^'o^). 

21.  From  13  and  using  Lemma  8.21  we  deduce  that  o  <i{M)  =0  o  This  and  19  allow 

us  to  prove  more  of  the  conclusion:  o  ^[M  N)  =3  o  ^(M'  N^). 

22.  From  4  and  using  Lemma  8.21  we  deduce  that  )  =0  Similarly 

from  8  we  get  that  o  ^^(^2)  =0  o  ^^(A^')/:z:]4^'  o  Now  we  can  use  Lemma  8.22 

with  12  and  19  to  get  the  last  part  of  the  conclusion:  4^'  o  =0  o  ^^(^2). 

This  concludes  all  the  cases  regarding  the  atomic  unification.  The  rest  of  the  cases  are  for  normal 
unification.  The  only  interesting  cases  here  are  the  abstraction  and  instantiation  cases. 

Case: 

M  ^  Af  ^  ♦ 

\x.M  ^  Xx.Af  ^  • 

The  empty  substitution  is  well-typed  and  also  placeholder- free.  By  hypothesis  F  F  Xx.M  :  A  and 
F  f  Xx,M'  :  A,  From  Lemma  8.14  we  have  that  A  —  Hj:  :  A1.A2  and  F^x  :  Ai  f  M  :  A2  and 
also  T^x  :  Ai  f  M'  :  ^2-  Now  we  can  use  the  induction  hypothesis  on  Vi  and  infer  the  required 
conclusion:  M  =0  M'. 

Case: 

n  ^  FV(M) 

u  ^  M  ii  ^  M 

Let  =  u  ^  M.  By  hypothesis  we  have  that  T  ^  u  :  A  and  F  P  M  :  A  and  PF{M).  From 
Corollary  8.18  we  deduce  that  F  h  Because  PF(M)  we  can  also  infer  that  PF(^).  The  rest  of 
the  conclusion  is  trivial:  ^(u)  ^^(M)  because  ^(M)  =  M. 

□ 


8.4  Correctness  of  Constraint  Collection  and  Constraint  Solving 

Due  to  the  presence  of  dependent  types  there  is  a  very  close  relationship  between  constraint  collec¬ 
tion  and  constraint  solving.  This  is  mainly  because  the  properties  for  constraint  solving  are  only 
defined  if  the  type  involved  is  well- typed  of  kind  Type.  However,  due  to  the  dependency  of  types 
on  terms  the  latter  property  of  types  may  depend  on  some  of  the  other  typing  constraints. 

Things  are  complicated  because  of  the  reconstruction  whose  results,  and  therefore  the  exact 
shape  of  future  typing  constraints,  depends  on  the  particular  order  chosen  for  solving.  If  the 
constraints  were  solved  in  order  then  by  the  time  a  constraint  is  about  to  be  solved  we  could 
prove  that  the  type  involved  is  well- formed  of  kind  Type.  We  cannot  assume  in-order  solving  of 
constraints  because  much  of  the  power  of  the  reconstruction  originates  in  the  ability  to  solve  the 
constraints  out-of-order. 

This  complicates  the  correctness  proof  substantially.  We  structure  the  proof  as  a  chain  of 
dependent  theorems,  two  for  each  of  the  constraint  collection  and  constraint  solving  judgments. 
Note  how  the  conclusion  of  one  theorem  establishes  the  assumptions  of  the  next  one. 
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We  start  with  a  theorem  about  the  goal  solving  judgment,  saying  that  during  constraint  list 
solving  each  typing  constraint  is  eventually  solved.  However,  depending  on  the  particular  order  of 
solving  some  placeholder  variables  may  be  already  instantiated,  hence  the 


Theorem  8.4  If  V  f  C  ^  then  for  each  N  :  A'  from  C  there  exist  and  ^<2  such  that 
«'i(r)  F  ^i(iV)  :  ^2- 


Proof:  (of  Theorem  8.4)  The  proof  is  by  induction  on  the  structure  of  th(i  derivation  D  ::  F  F  (7 
The  conclusion  is  vacuously  true  if  C  is  empty.  Also,  if  the  last  rule  in  V  is  the  reordering  rule, 
the  induction  hypothesis  proves  the  conclusion  directly.  The  other  two  case  are  similar  so  we  only 
show  here  the  case  when  the  last  rule  in  V  is  solving  a  typing  constraint. 

Case: 


V2 


rFM:A=»^  ^'(r)  F  ^'(C)  => 

~  rF(7,M: 

We  show  the  conclusion  separately  for  M  :  A  and  then  for  all  the  other  N  :  A'  from  C.  If 
M  :  A  is  the  considered  constraint  in  C,M  :  A  then  the  conclusion  follows  immediately  with 
=  •  and  ^2  =  Otherwise  let  AT  :  A'  be  a  typing  constraint  in  C.  Then  '^{N)  :  ^'(A')  is 
a  constraint  in  ^(C).  By  induction  hypothesis  on  X>2  we  get  that  there  exists  and  ^'2  such 
that  F  :  ’I’'i(^'(A'))  5'^.  This  proves  our  conclusion  with  the  required 

substitutions  iFi  =  o  ^  and  ^2  =  ^2- 

□ 

We  continue  now  with  a  theorem  about  the  constraint  collection  judgment.  Using  the  result  of 
the  previous  theorem  we  show  that  all  the  types  in  the  resulting  constraint  list  are  well-formed  and 
of  kind  Type. 


Theorem  8.5  // F  F  M  =>  (A  ;  C  ;  B)  with  PF(F)  and  PVF(M)  and  for  all  N  :  A'  in  C  there 
exist  ^1,  ^2  (ind  A'  such  that  ^i(F,  A,  A')  F  '^i{N)  :  ^i(A')  ^'2  then 

•  F,  A  F  B  :  Type,  and 

•  PF(A),  and 

•  PF(H),  and 

•  For  all  N  :  A'  in  C  we  have 


-  PF(A'),  and 

-  PVF(Ar),  and 

-  F,  A  F  A'  :  Type. 

Proof:  (of  Theorem  8.5)  The  proof  is  by  induction  on  the  structure  of  the  derivation  :  F  F  M 
{A  •,  C  ;  B).  There  are  4  cases  depending  on  the  last  rule  used  in  T>.  The  cases  for  constants  and 
variables  follow  immediately  as  the  A  and  the  list  of  constraints  are  empty  and  because  PF(F). 
The  only  interesting  cases  are  those  that  deal  with  application. 

Case: 

Vi 

^  FFM=^(A;C;nx:A.B)  .  ,  ,  ,, 

V  =  — -r- , , - TT - — -p; — r  ,  1  u  IS  a  new  placeholder  variable 

rFM*=^(A,u:A;C';  [u/x]B)  ^ 

We  can  immediately  apply  the  induction  hypothesis  on  Vi  and  obtain  that 
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1.  r,  A  I]iX:A,B  :  Type,  and 

2.  PF(A),  and 

3.  PF(na;:A.5),  and 

4.  For  all  AT :  in  C  we  have  F,  A  ^  :  Type,  and  PF(A)  and  PVF(iV). 

5.  Because  u  is  new  we  can  transform  4  in  F,  A,u  :  A  A'  :  Type,  which  proves  part  of  the 
conclusion. 

6.  Similarly,  from  1  we  deduce  that  F,  A,ii  :  A  F  [ulx]B  :  Type,  which  is  another  part  of  the 
conclusion. 

7.  From  2  and  3  we  can  show  that  PF(A,w  :  A) 

8.  From  3  we  show  that  PF{[u/x]B)^  which  concludes  the  proof  of  this  case. 

Case: 

FFM-^(A;(7;  Ux:A,B)  x  €  FV{B)  D  (PF(Ar)  and  PVF(A)  and  PVF(F(FV(7V)))) 

FFMAr^(A;C,iV:A;  [N/x]B) 

We  can  immediately  apply  the  induction  hypothesis  on  Vi  and  infer  that: 

1.  F,  A  F  UxiA.B  :  Type,  and 

2.  PF(A)  (part  of  the  conclusion),  and 

3.  PF{Ilx:A,B)^  and 

4.  For  all  TV'  :  A'  in  C  we  have  F,  A  F  A'  :  Type  and  PF(A')  and  PVF(TV')  (part  of  the 
conclusion) . 

5.  From  3  we  can  deduce  that  FF{[N/x]B)  (part  of  the  conclusion).  Note  that  we  have  used  the 
fact  that  if  a;  E  FV(5)  then  PF(iV). 

6.  The  only  part  of  the  conclusion  that  remains  to  be  proved  is  that  F,  A  F  [N/x]B  :  Type. 
If  X  ^  FV(J?)  then  this  follows  immediately  from  1.  Otherwise  is  suffices  to  prove  that 
F  F  TV  :  A. 

7.  By  hypothesis  we  have  that  there  exist  and  A'  such  that  ^^i(F,A,  A')  F  ^i(TV)  : 

^i{A)  ^  4^2- 

8.  But  PVF(A)  therefore  we  get  ^^i(A)  —  A. 

9.  Because  PVF(Tkf  TV)  (hypothesis)  we  know  that  PVF(TV). 

10.  Prom  9  we  conclude  that  ^i(TV)  =  TV. 

11.  With  8  and  10  we  transform  7  to  ^^i(F,  A,  A')  F  TV  :  A  =>  ^^2 

12.  But  because  PVF(TV)  then  none  of  the  placeholder  variables  from  A  and  A'  occur  in  TV. 
Therefore  we  can  transform  11  to  ^^i(F)  F  TV  :  A  ^2* 


38 


13,  We  know  that  PVF(r(FV(iV')))  therefore  we  can  transform  12  toT  f  N  :  ^2- 

14.  With  3  we  apply  Theorem  8.8  on  13  and  deduce  that  T  f  N  :  A.  As  motivated  at  6  this 
concludes  the  proof  of  this  case. 


□ 

We  continue  with  a  theorem  that  shown  that  the  constraint  solving  judgment,  when  presented 
with  constraints  whose  types  are  well-formed,  produces  a  well-typed  substitution  that  satisfies  the 
constraints. 


Theorem  8.6  //  F  F  C  with 

•  PF(r).  (W(l 

•  For  A  D  in  C  we  have  PF(A),  FF{B)  and  T  f  A  :  Type  and  F  F  5  :  Type,  and 

•  For  all  N  :  A'  in  C  we  have  PVF(iV)  and  PF(A')  and  F  F  A'  :  Type,  and 
then  the  follotrhuj  are  true: 

•  F  F  and 

•  PF(^').  and 

•  For  A  iff  C  we  have  ^(A)  and 

•  For  all  N  :  A'  in  C  we  have  ^(F)  F  N  :  ^(A') 


Proof:  (of  Theorem  8.6)  The  proof  is  by  induction  on  the  structure  of  the  derivation  D  :  F  F 

The  case  when  the  last  rule  in  V  is  the  reordering  rule  poses  no  problems.  Similarly  the  case  of  an 
empty  constraint  list  is  trivial.  We  show  next  the  case  when  the  last  rule  in  V  is  solving  a  typing 
constraint. 


Case: 


V2 


F  F  M  :  A  ’F  ^(F)  F  ^{C)  => 
FFC,M: 


Because  PF(F),  PF(A)  and  PVF(M)  and  F  F  A  :  Type  we  can  apply  Theorem  8.1  on  and  infer 
that  F  F  PF(^)  and  ^(F)  F  M  :  ^^(A). 

Because  the  substitution  ^  is  without  placeholders  and  is  well-typed,  the  constraint  list  "^{C) 
satisfies  all  the  conditions  for  applying  the  induction  hypothesis  on  V2  with  respect  to  the  type 
environment  ^(F).  We  deduce  from  the  induction  hypothesis  that  ^^(F)  F  and  PF(^^')  and  for 
all  W  :  A'  in  (7  that  o  ^(F)  F  W  :  o  Now  we  only  need  to  use  Lemma  8.19  to  conclude  the 
proof  of  this  case. 

The  case  when  a  unification  constraint  is  solved  is  very  similar  with  the  difference  that  Theorem  8.2 
is  invoked  to  show  that  the  unification  returns  a  well-typed  substitution. 

□ 

The  last  theorem  in  the  correctness  proof  of  the  reconstruction  algorithm  shows  why  the  exis¬ 
tence  of  a  well-typed  substitution  defined  on  all  locally  introduced  placeholder  variables  is  enough 
to  guarantee  the  well-typedness  of  the  original  term. 
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Theorem  8.7  IfTfM=^{A;C;B)  and 

•  r,  A  h  and 

•  PF(3’),  and 

•  Dom{A)  C  Dom{'^),  and 

•  For  all  N  :  A'  in  C  we  have  PVF(7V)  and  ^(F)  F  N  :  ^(^') 
then  «'(r)  F  M  :  ^{B). 

Proof:  (of  Theorem  8.7)  The  proof  is  by  induction  on  the  structure  of  th(?  derivation  V  y.r  f  M 
{A  ;  C  ;  B).  The  cases  of  a  constant  or  a  variable  follow  immediately  from  the  hypothesis.  We 
consider  next  the  cases  of  application  to  explicit  terms  and  to  placeholders  next. 

Case: 


2?i 

r  F  M  (A  ;  C  ;  Ux-.A.B)  x  e  FY{B)  D  (PF(iV)  and  PVF(7l)  and  PVF(r(FV(iV)))) 

rFMiV=^(A;C',7V:^;  [N/x]B} 


We  can  immediately  apply  the  induction  hypothesis  on  Vy  and  we  conclude  that  ^(F)  F  M  : 

A.B).  From  the  hypothesis  we  have  that  PVF(iV’)  and  ^(F)  F  N  :  ^'(^4).  From  the  application 
rule  in  LFj,  and  because  PVF(iV)  we  deduce  that  ^(F)  F  iVF  N  :  4'([lV/x]i?).  Note  that  the  newly 
introduced  type  [N/x]B  is  without  placeholders  because  if  x  occurs  in  B  then  PF{N). 

Case: 

Vi 

FFM=>  {A-,C  ;Ux:A.B) 


V 


F  F  ilF  *  =>  (A,  u  A  C  \u/x\B) 

Let  =  ^|r,A  •  We  follow  a  sequence  of  deductions  as  follows: 


u  is  a  new  placeholder  variable 


1.  From  F,  A,«  :  .4  F  ^  (hypothesis)  and  Dom{A,u  :  A)  C  Dom{'^)  (hypothesis)  we  deduce: 


2.  ^{F,A,u  :  A)  F  ^(u)  :  «'(^),  and 

3.  Dom{A)  C  Dom{^'). 

4.  Because  Dom(A,u  :  A)  C  Dom{^)  we  have  that  ^(F,  A,«  :  A)  =  ^'(F). 

5.  From  2  and  4  we  infer  that  ^(F)  F  ^'(u)  :  ^(.A). 

6.  From  Lemma  8.20  and  1  we  have  that  F,  A  F  4/'.  Also  because  u  is  new  it  cannot  appear  in 
C  or  in  F.  Therefore  we  can  deduce  that  for  all  N  :  A'  in  C  we  have  ^’'(F)  F  N  :  ^''(A'). 
Thus  we  can  apply  the  induction  hypothesis  on  Pi  and  conclude  that 


7.  'i!'iF)fM:Ux:'^'{A).'^'{B). 

8.  Again,  because  u  is  new  it  cannot  appear  in  F,  M,  A  or  B.  Therefore,  from  7  we  deduce  that 
4'(F)  FM:na;:^(A).4f(B). 

9.  Recall  that  we  assume  that  all  types  involved  are  without  placeholders.  Thus,  PF(^'(A))  and 
therefore  PF(^'(A)). 
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10.  Now  we  can  use  the  implicit  application  rule  of  LF^  with  5,  8  and  9  and  with  the  placeholder 
replacement  being  ^(u).  The  resulting  type  is  [^{u)/x]^{B)  = 

11,  This  case  is  not  complete  until  we  verify  that  the  newly  introduced  type  ^([w/x]S)  is  without 
placeholders.  This  follows  immediately  from  the  PF(^^(nx:  A.^))  and  PF(^^). 

Note  that  this  is  the  place  where  we  require  the  property  that  $  be  well-typed  and  defined  for  all 
variables  in  A. 

□ 

This  concludes  the  skeleton  of  the  correctness  proof  for  the  reconstruction  algorithm.  In  the 
rest  of  this  section  we  have  the  proofs  of  the  helper  lemmas  used  in  the  correctness  proofs.  We 
start  first  with  a  family  of  theorems  mirroring  the  correctness  proof  but  in  the  special  case  when 
the  terms  involved  are  fully-reconstructed. 

8.5  Correctness  in  the  Pully-Explicit  Case 

As  part  of  the  correctness  of  the  reconstruction  algorithm  we  make  use  of  the  correctness  of  the 
algorithm  in  the  case  when  both  the  LF  term  and  type  involved  do  not  contain  placeholders  or 
placeholder  variables.  The  correctness  proof  in  the  fully-explicit  form  follows  the  same  pattern  as 
the  proof  in  the  general  case,  with  some  simplifications.  We  do  not  show  here  a  complete  proof  of 
this  case.  We  just  state  the  lemmas  involved. 

Theorem  8.8  If  T  f  M  :  A  ^  and  PF(r),  PF(M),  PF(A),  PVF(M),  PVF(A)  and 
PVF(r(FV(M)))  then  ^  -  andV  f  M  :.A, 

Proof:  The  proof  of  this  theorem  is  done  similarly  to  that  of  Theorem  8.1  by  induction  on  the 
derivation  V  :  T  f  M  :  A  The  abstraction  case  is  simple.  For  the  application  case  we  need 

a  series  of  auxiliary  lemmas  about  the  constraint  collection  and  solving  judgments  in  the  case  of 
fully-explicit  terms  and  types.  These  lemmas  are  stated  without  proof  below. 

□ 

Lemma  8.9  //F  F  M  (A  ;  C  ;  S)  and  PF(r),  PF(M),  PVF(M)  and  PVF(r(FV(M)))  then 

•  A  —  and 

•  PF(S)  and  PVF(5),  and 

•  For  all  N  :  A^  in  C  we  have  that  PF(7V),  PVF(7V),  PF(A')  and  PVF(A')  and 
PVF(r(FV(JV))). 

The  intuition  behind  Lemma  8.9  is  that  because  M  does  not  have  placeholders,  no  placeholder 
variables  are  introduced,  hence  A  =  •.  Also  the  terms  in  C  are  subterms  of  M  and  therefore  do 
not  contain  placeholders  or  placeholder  variables  and  also  all  their  free  variables  have  types  that  do 
not  contain  placeholder  variables.  The  types  in  C  and  B  are  constructed  from  fully-explicit  types 
(because  PF(r)  and  PVF(r(FV(M))))  with  subterms  of  M,  hence  the  condition  on  types. 

Lemma  8.10  If  A B  ^  and  PVF(A)  and  PYF{B)  then 

•  ^  =  and 

•  A  =^B 
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The  lemma  above  is  proved  by  induction  on  the  structure  of  the  unification  judgment.  The 
intuition  behind  it  is  that  if  the  terms  to  be  unified  do  not  contain  placeholder  variables  then  the 
resulting  substitution  must  be  empty.  In  this  case  the  two  terms  are  /?-equi valent. 

Lemma  8.11  IfrfC,A^aB=>^and  PF(r),  PF(^),  PVF(^),  PF{B),  PVF(S)  and  for  all 
N  :  A'  in  C  we  have  PF{N),  PVF(iV),  PF(^'),  PVF(^')  and  PVF(r(FV(iV)))  then 

•  =  -j  and 

•  A  =,s  By  and 

•  F^  N  :A^  for  all  N  :  A'  in  C 

Th(‘  proof  of  Lemma  8.11  is  by  induction  on  the  structure  of  the  derivation  F  F  C,  A 
\Vh(Mi  a  unification  is  solved  we  use  Lemma  8.10  to  conclude  that  the  resulting  substitution  is  empty 
and  that  the  unified  types  are  ^-equivalent.  When  a  typing  constraint  is  solved  then  the  hypothesis 
provid('s  all  the  conditions  necessary  to  apply  Theorem  8.8  and  conclude  again  that  the  substitution 
is  (Miipiy  and  that  the  typing  constraints  are  satisfied. 

Lemma  8.12  //  F  F  M  =>  (•  ;  C  ;  ^)  and  A  =0  B  with  PF(A)  and  for  all  N  :  A'  in  C  we  have 
r  F  .V  :  A'  and  PF(Fl')  then  F  f  M  :  A, 

We  prove  Lemma  8.12  by  induction  on  the  structure  of  the  collection  derivation.  Again  We  can¬ 
not  hav('  placeholders  and  because  the  typing  constraints  from  C  are  satisfied  we  can  immediately 
pn)V(‘  the  conclusion  using  the  typing  rules  of  LF^. 

8.6  Soundness  of  LF^  typing 

\V('  have  proved  the  correctness  of  the  reconstruction  algorithm  with  respect  to  the  LF^  typing 
system.  In  order  to  complete  the  proof  of  adequacy  of  the  reconstruction  algorithm  for  checking 
I)roofs  we  still  have  to  prove  Theorem  5.1,  that  is  the  soundness  of  LF^  typing  with  respect  to  LF 
typing.  We  do  this  in  the  rest  of  this  section.  For  clarity  we  restate  the  theorem  here. 

Theorem  8.13  Soundness  of  LF^  typing  IfFFMiA  and  PF(F),  PF(A),  then  there  exists 
M'  such  that  M  M'  and  F^  :  A. 

Proof:  The  proof  is  by  induction  on  the  structure  of  the  derivation  V  :  F  F  M  :  A,  The  case  of  a 
constant  or  a  variable  is  trivial.  In  the  case  of  the  /?-equivalence  rule  we  use  the  rule  hypothesis 
PF(A)  to  apply  the  induction  hypothesis  and  then  we  use  the  LF  /?-equivalence  rule. 

In  the  case  of  an  abstraction  again  we  use  the  theorem  hypothesis  PFfFlx :  A.B)  to  ensure  that 
we  can  apply  the  induction  hypothesis.  The  remaining  cases  deal  with  the  application  to  a  term  or 
a  placeholder. 

Case: 

rfM:Ux:A.B  FFW:A  PF(A) 

F  F  M  *  :  [N/x]B 

Because  of  the  rule  hypothesis  PF(A)  we  can  apply  the  induction  hypothesis  on  T>2  and  deduce 
that  there  exists  iV'  such  that  N  and  F  W'  :  A. 

From  the  theorem  hypothesis  we  have  that  PF([A/’/a:]5).  Prom  here  we  infer  that  PF(J5)  and  then 
that  PF(na:;:  A.B).  This  justifies  applying  the  induction  hypothesis  to  Vi  and  inferring  that  there 
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exists  M'  such  that  M  z'  M'  and  F  M'  :  Ha: :  A.B.  Now  using  the  LF  application  rule  we  infer 
that  r  M'  iV'  :  [N'/x]B.  It  is  evident  that  M  *  /•  M'  N' .  What  remains  to  be  proved  is  that 
[N' lx]B  =13  [N/x]B.  This  is  that  case  if  a;  0  FY{B).  Otherwise,  we  know  from  the  hypothesis  that 
PF([iV/a;]5)  which  implies  that  PF(Ar)  and  then  that  N  =  N'. 

The  case  when  the  last  rule  in  V  is  an  application  to  a  term  is  very  similar  to  the  case  presented 
above. 

□ 


8.7  Auxiliary  Lemmas 

The  following  lemmas  are  results  that  were  used  in  the  correctness  proof  of  the  type  reconstruction 
algorithm.  Most  of  them  are  trivial  to  prove  and  therefore  we  omit  their  proof.  Recall  also  that  we 
made  the  convention  that  all  the  types  involved  in  the  statements  of  the  theorems  and  lemmas  are 
placeholder-free. 

The  first  lemma  establishes  some  canonical  forms  of  types  in  LFj  judgments. 

Lemma  8.14  IfTFMiA  then  the  following  are  true: 

•  If  M  =  X  then  r(3;)  A 

•  If  M  =  c  then  S(c)  A 

•  If  M  =  Ml  M2  then  P  F  Mi  :  Ilx:Ai.A2  and  P  P  M2  :  Ai  and  [M2lx]A2  =0  A 

•  If  M  =  Xx.N  then  A  =  I[x\Ai.A2  and  P,a;  •.  Aif  M  :  A2. 

Next  we  have  a  lemma  saying  that  /3-reduction  “preserves”  the  type  of  the  expression.  Because 
of  the  dependent  types  the  resulting  type  is  actually  obtained  by  substitution  itself. 

Lemma  8.15  IfTf  Xx.M  :Ux:A.B  andT  f  N  :  A  with  PF(iV)  then  P  f  [N/x]M  :  [N/x]B. 

We  continue  with  a  crucial  lemma  used  throughout  the  proof  of  correctness.  This  lemma  says 
that  if  a  substitution  is  well-typed  on  certain  placeholder  variables  then  it  preserves  the  typing 
relation. 

Lemma  8.16  Let  D  =  Dom(^’)nFV(M)  */PF(M)  and  Dom{'^)  otherwise.  If  PF{'^)  and  ^(P) 
vf(u)  :  ^(P(u))  for  all  u  E  D  and  if  F  f  M  :  A  then  ^(P)  ^'(M)  :  ^{A). 

Proof:  (of  Lemma  8.16)  The  proof  is  by  induction  on  the  structure  of  the  derivation  ::  P  M  :  A. 
The  case  of  a  constant  is  trivial  because  the  constant  and  its  type  do  not  change  by  substitution. 
More  interesting  cases  are  when  M  is  a  variable  or  a  placeholder  variable.  In  the  case  of  a  normal 
variable,  or  a  placeholder  variable  outside  Dom{'^),  the  conclusion  follows  inomediately  from  the 
definition  of  ^(P).  In  the  case  of  a  placeholder  variable  that  is  in  Dom(’F)  the  conclusion  follows 
from  the  hypothesis  because  that  variable  is  also  in  FV  (M)  and  therefore  in  D. 

We  consider  the  other  cases  below: 

Case: 

Vi 

^  FfM:A  A=0B  PF(A) 

PI^M:B 

In  this  case  we  can  apply  the  induction  hypothesis  on  Vi  and  infer  that  ^(P)  ^(M)  :  ’5' (A). 

Note  that  we  have  used  the  hypothesis  PF(^)  to  ensure  that  our  implicit  convention  about  types  is 
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preserved.  By  Lemma  8.21  we  get  that  ^(.A)  A'(B).  Because  PF(A')  and  PF(^)  we  deduce  that 

PF(^(A.)).  We  can  therefore  use  the  LFj  rule  for  beta-equivalence  and  infer  that  ^(P)  P  ^’(M)  : 

^(B). 

Case: 


VfXx.M:Iix:A.B 


The  set  of  placeholder  variables  D  is  the  same  for  Xx.M  and  M.  We  know  that  for  all  u  G  D  we 
have  A'(r)  P  ’^>{u)  :  ^'(r(u)).  Because  x  cannot  occur  in  ^  we  deduce  that  'F(r,a;  :  A)  ^(u)  : 
^((r,a;  :  A)(u))  for  all  u  E  D.  We  can  therefore  apply  the  induction  hypothesis  and  conclude  that 
A)  f  ^^(M)  :  Prom  here  we  can  use  the  abstraction  rule  of  LF^  and  deduce  the 

desired  conclusion  ^^(r)  f  '^{Xx.M)  : 

Case: 


Vl  I>2 


rfM:Ux:A,B  VfNiA  FF{A) 

rfMN:  [N/x]B 


We  know  that  PF(M  N)  iff  PF(M)  and  PF{N),  This  and  the  fact  that  the  free  variables  of  M  and 
N  are  among  those  of  M  N  allow  us  to  use  the  induction  hypothesis  both  on  T>i  and  V2-  Because 
PF(v4)  and  PF(^)  we  have  that  PF(^^(^)  which  can  be  used  together  with  the  induction  hypotheses 
to  infer  the  desired  conclusion  ^^(r)  N)  :  '^{[N/x]B).  Note  that  by  our  implicit  convention 

on  types  we  have  that  PF([7V/ic]S)  which  implies  that  PF(S)  and  also  that  PF{Ilx:A,B), 

Case: 


Vl  V2 


VP  M  :Iix:A.B  VpNiA  PF{A) 
r Pm ^ :  [Nyx]B 


Note  that  in  this  case  we  do  not  have  PF(M  *)  and  therefore  we  must  have  P  P  We  can  therefore 
apply  the  induction  hypothesis  for  the  derivation  Vi  and  infer  that  ^^(r)  ^^(M)  : 

Prom  the  induction  hypothesis  on  V2  we  infer  that  ^^(r)  ^{N)  :  ^(A).  Prom  here  we  follow  the 

same  steps  as  in  the  previous  case.  Note  that  ^(M  *)  =  ^{M)  *. 

□ 


The  Lemma  8.16  is  not  actually  used  in  that  form.  All  its  uses  are  in  the  form  of  two  corollaries 
stated  below. 


Corollary  8.17  IfTpM:AandT\-^  with  PF(^)  then  ^^(r)  ^  ^{M)  :  >P(A). 

Proof:  (of  Corollary  8.17)  The  corollary  follows  immediately  from  Lemma  8.16  if  we  note  that 
D  C  Dom{^)  and  that  P  h  implies  that  for  all  u  E  Dom{^)  we  have  ^^(P)  :  ^(r{u)). 

□ 


Corollary  8.18  IfVPuiA  and  F  P  M  :  A  with  PF(M)  and  u  0  FV(M)  then  P  1^  w  ^  M. 

Proof:  (of  Corollary  8.18)  Let  "it  =  u  E-  M.  Because  PF(M)  we  can  apply  Lemma  8.16  with 
D  =  Z)om(^)  n  FV(M)  =  0  and  we  infer  that  ^^(P)  ^^(M)  :  ^(A).  But  because  u  0  FV(M)  we 

have  that  '^{M)  =  M  =  Therefore  P  H 

□ 

We  continue  with  two  lemmas  dealing  with  typing  substitution.  The  first  is  concerned  with 
the  well-typedness  of  a  composition  of  two  substitutions.  The  second  one  deals  with  restricted 
substitutions. 
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Lemma  8.19  and  ^(F)  \-  with  PF(^)  and  PF(^^')  then  F  h  o  ^  and  PF(^^'  o 

Proof:  It  is  obvious  that  PF(^'  o  >F).  To  prove  that  F  h  o  ^  consider  a  placeholder  variable 
u  E  Dom{'^'  o  ^).  Then  either  u  E  Dom{^)^  in  which  case  (Gamma)  f  ^(u)  :  ?^(F(u))  and  by 
Lemma  8.16  we  get  the  desired  conclusion,  or  u  E  in  which  case  ^^'(^^(F))  P 

:  ^'(^(F(u))). 

□ 

Lemma  8.20  //F,  A  h  ^  and  Dom{A)  C  Domi"^)  then  ^(F,  A)  =  ^^(F)  =  ^|r>om(r)  (I^) 
r  P  ^|Dom(r)  • 

Proof:  It  is  easy  to  prove  that  ^^(F,  A)  =  ^(F)  using  the  definition  of  substitution  applied  to  type 
environments.  Also  it  must  be  the  case  that  F  does  not  contain  any  placeholder  variable  contained 
in  A,  thus  we  get  ^^(F)  ==  ^|/)am(r)  (r). 

For  the  second  part,  let  u  E  Doml^it)  fl  Dom{T).  We  have  that  ^(F)  f  '^(u)  :  ^(F(n)).  Becaus'e 
nothing  in  A  can  occur  in  F  we  conclude  that  F  P  3'|/}o7n(r)  • 

□ 

The  last  lemmas  required  are  concerned  with  /3-equivalence.  Their  proof  is  trivial  so  we  just 
state  them  here. 

Lemma  8.21  If  M  N  then  ^(M)  ^^(TV’). 

Lemma  8.22  If  M  N  and  M'  TV'  then  [M/x]M'  [N/x]N'. 
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9  An  Optimized  Version  of  Type  Reconstruction 

In  this  section  we  examine  several  optimizations  to  the  reconstruction  algorithm  presented  in  Sec¬ 
tion  6.  We  chose  to  present  these  optimizations  separately  from  the  main  algorithm  to  simplify  the 
presentation  of  the  algorithm  and  its  correctness  proof,  and  also  because  the  behavior  and  power 
of  the  reconstruction  is  not  influenced  by  these  optimizations.  Their  only  purpose  is  to  lay  the 
grounds  for  an  efficient  implementation  of  the  algorithm,  which  will  be  discussed  in  Section  10. 

Because  the  optimizations  presented  in  this  section  were  not  proved  correct  as  part  of  the  main 
correctness  theorem  we  have  the  obligation  of  proving  their  correctness  here.  However,  in  order  to 
simplify  the  presentation  we  are  only  showing  informal  correctness  arguments. 

We  consid('r  two  classes  of  optimizations.  The  first  class  consists  of  signature-independent  opti¬ 
mizations  wh()S('  focus  is  to  optimize  the  checking  of  the  side  conditions  present  in  the  reconstruction 
algorithm.  Exainpk's  of  signature-independent  optimizations  are  the  occurs  check  optimization  and 
an  optimization  of  the  complicated  side  condition  from  the  collection  rule  for  explicit  parameters. 
We  show  ill  Figun'  IG  on  page  51  a  variant  of  the  reconstruction  algorithm  that  incorporates  these 
optimizations. 

The  second  chiss  of  optimizations  are  dependent  on  the  particular  signature  that  is  at  the  base 
of  reconstruction.  The  reason  we  are  interested  in  such  optimizations  is  that  in  all  of  our  current 
experiments  w<'  an'  interested  in  using  the  reconstruction  as  the  basis  for  validating  first-order  logic 
proofs.  In  such  conditions  we  can  eliminate  some  of  the  side-condition  checks  without  compromising 
the  correctiK'ss  of  tlie  reconstruction. 

9.1  Optimizing  the  Occurs  Check 

One  of  the  most  important  features  of  our  reconstruction  algorithm  is  that  the  reconstructed 
subterms  do  not  have  to  be  typechecked  because,  by  design,  the  algorithm  ensures  that  they  are 
well-typed.  This  saves  a  lot  of  time  when  validating  proofs. 

If  we  examine  the  unoptimized  algorithm  we  notice  that  the  basic  reconstruction  step  is  a 
placeholder- variable  instantiation  in  the  unification  judgment.  Whenever  a  new  instantiation  is 
made,  the  algorithm  scans  the  reconstructed  term  to  perform  the  occurs  check.  This  operation  is 
less  expensive  than  complete  typechecking  but  still  detracts  from  the  performance  advantage  of  the 
reconstruction  versus  the  validation  of  fully-explicit  terms. 

We  have  discovered  that  in  most  of  our  experiments  the  occurs  check  is  not  necessary.  This 
section  presents  the  results  of  our  efforts  to  isolate  as  precisely  as  possible  the  cases  when  the 
absence  of  the  occurs  check  could  lead  to  inconsistencies.  The  optimization  presented  in  this 
section  recovered  about  90%  of  the  cost  of  occurs  check  in  our  experiments  with  proof  validation 
for  first-order  logic. 

The  basic  idea  behind  the  occurs-check  optimization  is  that  most  placeholder  variables  occur 
at  most  once  and  in  at  most  one  of  the  terms  involved  in  a  unification  operation.  When  such  a 
variable  is  instantiated  the  occurs  check  is  obviously  not  necessary.  The  rest  of  the  section  presents 
how  we  identify  the  placeholder  variables  that  have  this  linearity  attribute  and  how  we  ensure  that 
the  attribute  is  preserved  as  the  unification  goes  along. 

We  attach  a  linearity  attribute  to  each  placeholder  variable  to  identify  those  placeholder  vari¬ 
ables  that  occur  at  most  once  and  in  at  most  one  of  the  unified  terms.  We  write  to  denote  that 
the  placeholder  variable  u  is  linear  and  we  write  vP'  to  denote  that  u  is  non-linear.  We  reserve  the 
notation  u  for  situations  where  the  linearity  attribute  of  u  is  not  relevant.  The  purpose  of  this 
labelling  is  to  be  able  to  isolate  the  instantiation  operations  that  do  not  require  an  occurs  check  by 
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means  of  a  new  instantiation  rule: 


^  M  ^  M 

The  first  task  is  to  label  the  placeholder  variables  as  they  are  introduced  in  the  collection  rule 
for  implicit  application.  In  order  to  determine  the  labelling  we  define  the  judgment  linear{x^Ilxi : 

_ Tlxn  :  An>An^i)  to  denote  that  the  variable  x  occurs  at  most  once  in  any  Ai  component  of 

the  typo.  This  notion  is  formalized  below  using  the  notation  x  €<i  FV(yl)  to  denote  that  x  has  at 
most  one  free  occurrence  in  A. 

linear{x,B)  a:G<iFV(A)  xE<iFY{A) 
linear  {x^  Ily:A.B)  linear  {x,  A) 

Tlu'  variable  labelling  is  done  using  an  additional  modified  version  of  the  collection  rule  which 
lab(»ls  linear  placeholder  variables: 


r  F  M  (A  ;  C  ;  Ux:A,B)  linear {x,B) 
r  f  M  *  {A,u^  A  ;  C  ■,  [u^/x]B) 

111  most  cases  the  linearity  check  has  a  small  rumtime  cost.  This  is  because  whenever  the  head 
of  M  is  a  constant  the  linearity  predicate  can  be  computed  statically  and  cached  in  the  signature. 
For  (^xanij)le  if  the  head  of  M  is  the  constant  and-i  of  type 


Yix\  :pred  ..11x2  :pred  --IIxs  :pf  xi..nx4  :pf  X2..pf  (and  xi  X2) 

th('  all  the  variables  introduced  in  the  collection  for  M  are  linear.  However,  if  the  head  is  eq_id  of 
type 

Hxi :  exp  ..pf  (—  xi  xi) 

the  variable  x\  is  not  linear  because  it  occurs  twice  in  the  same  atomic  component  of  the  type.  If 
the  head  of  M  is  a  variable  we  can  simply  use  the  usual  non-linear  collection  rule  and  avoid  the 
check.  Note  that  we  do  not  jeopardize  the  correctness  of  the  algorithm  by  having  too  few  linearity 
labels. 

We  can  state  the  linearity  property  in  terms  of  the  logic  inference  rules  that  the  constants  in  S 
represent.  A  logic  variable  is  linear  in  an  inference  rule  if  it  appears  at  most  once  in  the  conclusion 
and  at  most  once  in  each  of  the  hypotheses  of  the  inference  rule. 

Just  identifying  the  linear  placeholder  variables  is  not  sufficient.  In  order  to  motivate  the  other 
changes  to  the  reconstruction  rules  we  first  state  our  goals  in  the  form  of  a  list  of  invariants  that 
we  want  to  preserve  throughout  reconstruction.  These  invariants  also  serve  as  the  basis  for  the 
informal  correctness  arguments,  and  can  be  viewed  as  informal  statements  of  a  series  of  correctness 
theorems. 

Invariants: 

1.  In  all  judgments  we  never  have  simultaneous  occurrences  of  both  the  linear  and  the  non-linear 
versions  of  a  placeholder  variable.  That  is,  the  linearity  property  is  attached  to  a  variable  and 
not  to  its  occurrences. 

2.  Whenever  a  unification  judgment  is  invoked  all  linear  variables  occur  at  most  once  in  at  most 
one  of  the  terms  to  be  unified. 
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3.  All  substitutions  have  the  property  that  non-linear  variables  are  instantiated  to  terms  contain¬ 
ing  only  non-linear  variables. 

It  is  clear  that  if  the  above  invariants  hold  then  it  is  safe  to  omit  the  occurs  check  when  a  linear 
variable  is  unified.  Next  we  show  the  modifications  that  are  required  in  order  to  preserve  these 
invariants. 

Substitutions  are  produced  by  the  instantiation  rule  and  are  then  transformed  using  compo¬ 
sition  and  restriction.  It  is  easy  to  see  that  substitution  composition  and  restriction  preserve  the 
substitution  invariant.  The  only  remaining  fact  to  check  about  substitutions  is  that  the  invariant 
holds  on  a  newly  produced  instantiations.  Substitutions  introduced  by  the  linear  instantiation  rule 
are  not  a  problem.  However,  in  order  to  establish  the  invariant  in  the  case  of  a  non-linear  in¬ 
stantiation  we  must  change  the  instantiation  rule  to  instantiate  non-linear  variables  only  to  terms 
containing  non-linear  variables. 

For  this  purpose  we  define  the  operation  Nonlinear(M)  ^  to  produce  a  substitution  con¬ 
taining  only  mappings  of  the  form  ^  for  all  linear  variables  occurring  in  M.  The  modified 
version  of  the  non-linear  instantiation  rule  is: 


u  0  FV(M)  Nonlinear{M)  ^ 
^  M  ^  M] 


u_inst 


Similarly  we  need  to  modify  the  /3-reduction  unification  rule  to  prevent  linear  variables  to  be 
duplicated  by  /3-reduction. 


Nonlinear {N)  ^  ^  [^{N)/x]M  ^ 

-  — - . ; - 1 - au._bet  a 

(Xx.M)  N^aM^  ^  o  ^ 

Note  that  whenever  we  change  the  linearity  attribute  of  a  variable,  the  fact  is  recorded  in  the 
substitution  produced  by  the  Nonlinear  function  so  that  we  can  do  the  change  globally.  This 
ensures  that  the  linearity  attribute  is  global. 

The  most  important  invariant  from  the  list  above  is  the  one  about  unification.  We  can  show  that 
this  invariant  is  preserved  throughout  unification.  The  only  difficult  case  here  is  the  application 
case.  We  can  prove  the  invariant  preservation  in  this  case  if  we  observe  the  following  properties  of 
substitutions  produced  by  unification: 

•  If  M  «  TV  then  ^  can  contain  only  variables  that  occur  in  M  or  TV. 

•  If  M  ^  N  then  any  linear  variable  appears  at  most  once  in  at  most  one  of  the  instanti¬ 

ations  from 

The  most  difficult  property  to  show  is  that  when  unification  is  invoked  from  the  constraint 
solving  judgment  the  unification  invariant  holds.  In  order  to  do  this  we  must  observe  that  the 
following  invariants  hold: 

Invariants: 

4.  If  M  ^  N  ^  and  £  Dom{^)  nFV(TW')  and  E  FV(^(w^))  then  G  FV(TV). 

5.  No  placeholder  variable  that  appears  in  r(a;)  for  some  x,  is  instantiated  until  x  :  A  is  retracted 
from  r. 
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6,  Whenever  T  f  M  :  A  =>  is  invoked^  all  linear  variables  occur  at  most  once  in  A,  Also,  the 
resulting  substitution  does  not  contain  instantiations  that  contain  linear  variables. 

The  first  invariant  above  is  shown  by  induction  on  the  unification  judgment  using  the  fact  that 
linear  variables  appear  at  most  once  in  at  most  one  side  of  the  unification.  The  second  invariant 
is  motivated  by  the  fact  that  only  the  empty  substitution  can  be  the  result  of  type-checking  an 
abstraction. 

In  order  to  show  the  last  invariant  we  note  that  type-checking  judgments  are  only  invoked  from 
the  constraint  solving  judgment,  which  in  turn  is  invoked  after  a  constraint  list  C  was  produced 
by  the  judgment  F  F  M  =>  (A  ;  C  ;  S).  If  TV'  :  is  a  component  of  a  constraint  list  C  we  notice 
that  A^  has  the  linearity  attribute  and  furthermore  it  only  contains  linear  variables  from  the  newly 
introduced  set  A.^  Also,  if  A  5  is  a  unification  constraint  in  C  we  notice  that  the  linearity 
invariant  is  established  initially  and  furthermore  the  linear  variables  in  A  are  not  in  A,  while  all 
the  linear  variables  in  B  are  in  A. 

The  last  proof  obligation  is  to  show  that  while  doing  constraint  solving  followed  by  the  transfor¬ 
mation  of  the  remaining  list  with  the  intermediate  substitution,  the  linearity  invariant  is  preserved. 
This  can  be  done  separately  for  the  cases  when  the  first  goal  solved  is  a  unification  goal  or  a  typing 
goal.  For  this  purpose  we  use  the  substitution  invariants  mentioned  above. 

As  shown  in  Section  11,  this  occurs-check  optimization  is  very  effective  when  checking  proofs 
in  first-order  logics.  This  is  because  all  the  applications  have  a  constant  head  and  we  do  not  loose 
anything  by  not  optimizing  the  case  of  variable  heads.  Another  and  a  more  important  reason  is 
that  the  vast  majority  of  inference  rule  in  a  typical  logic  are  completely  linear.  For  example  all  the 
inference  rule  of  first-order  predicate  logic  are  linear.  In  our  experiments  we  only  use  non-linear 
rules  that  deal  with  arithmetic  and  even  in  that  case  only  a  part  of  the  variables  are  non-linear. 
We  have  measured  reductions  of  up  to  90%  in  the  cost  of  the  “occurs”  check  when  checking  proofs 
of  first-order  logic.  This  translated  to  reductions  of  up  to  60%  in  the  total  cost  of  proof  validation. 
These  numbers  were  measured  for  an  implementation  that  contains  other  optimizations,  some  of 
which  make  the  cost  of  computing  the  Nonlinear  function  negligible. 

9.2  Optimizing  the  Side  Conditions 

The  largest  opportunity  for  optimization  in  the  reconstruction  algorithm  is  given  by  the  side  condi¬ 
tions.  In  the  previous  section  we  presented  such  an  optimization  for  the  occurs-check  side  condition. 
Another  side  condition  that  can  be  optimized  is  the  one  in  the  collection  rule  for  application  to  an 
explicit  term. 

This  side  condition  involves  four  checks  in  the  worst  case: 

a;  E  FV{B)  D  {PF{N)  and  PVF(A)  and  PVF(r(FV(Ar)))) 

We  note  first  that  the  check  x  E  FY{B)  can  be  precomputed  in  the  cases  when  the  head  of 
M  is  a  constant  in  a  similar  way  as  we  precomputed  the  linearity  predicate  for  the  occurs  check 
optimization. 

We  focus  on  the  checks  on  N  and  we  ignore  here  the  check  PVF(A).  The  basic  idea  here  is 
that  N  is  collected  in  the  typing  constraint  list  and  is  eventually  type-checked.  Therefore,  instead 
of  checking  the  conditions  on  N  eagerly  at  the  time  of  collection,  we  just  mark  that  they  should  be 

^Except  perhaps  some  linear  variable  occurring  in  some  r(x).  But  we  argued  before  that  these  are  never  instan- 
tiated  while  solving  the  current  constraint  list,  and  therefore  we  can  ignore  them  here. 
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checked  at  the  time  N  is  checked.  As  shown  in  Section  11,  this  is  an  effective  optimization  because 
delaying  the  checks  has  the  potential  of  collapsing  multiple  checks  into  a  single  one. 

Whenever  N  is  added  to  the  typing  constraint  list  we  set  a  flag  marking  that  when  N  is 
typechecked  we  should  also  verify  that  it  does  not  contain  placeholders  and  all  variables  free  in 
it  have  types  that  do  not  contain  placeholder  variables.  We  call  this  flag  p  and  we  write  the  new 
reconstruction  judgment  as  F  1^  M  :  A  The  flag  p  can  have  either  the  value  full,  meaning 

that  the  term  M  cannot  contain  placeholders,  or  implicit  otherwise.  The  initial  value  of  the  flag 
is  implicit. 

With  this  extra  flag  we  can  delay  the  side-condition  check  from  the  collection  rule  to  when  the 
explicit  argument  is  typechecked.  The  new  reconstruction  judgments,  implementing  this  optimiza¬ 
tion  and  also  the  occurs-check  optimization  are  shown  in  Figure  16. 

9.3  Optimizations  Specific  to  First-Order  Logics 

The  optimization  presented  in  Section  9.2  optimized  the  checking  of  a  complicated  side  condition 
from  the  constraint  collecting  rule.  As  a  result  of  this  optimization,  the  side  condition  was  split  in 
several  parts.  Among  these  the  most  expensive  are  the  side  conditions  from  the  rules  cc_x  (checking 
that  the  type  of  a  variable  does  not  contain  placeholder  variables)  and  cc_dep  (checking  that  a  type 
does  not  contain  placeholder  variables). 

In  certain  situations  these  residual  checks  can  be  omitted  altogether.  This  section  shows  that 
this  is  the  case  if  we  restrict  our  attention  to  checking  proofs  of  first-order  logic  predicates. 

For  the  purpose  of  this  section  we  restrict  our  attention  to  reconstruction  in  the  case  when  the 
signature  E  is  the  representation  of  a  first-order  logic,  using  as  an  example  the  representation  of 
the  logic  C  introduced  in  Section  2. 

By  inspection  of  the  signature  S  we  realize  that  the  only  dependent  type  family  is  pf  :  pred  -> 
Type.  Also  by  inspecting  the  predicate  constructors  we  notice  that  only  objects  of  type  exp,  pred 
and  exp  pred  can  occur  in  normal-form  predicates.  From  this  we  conclude  that  the  only  type 
dependency  in  S  is  on  objects  of  type  pred,  exp  and  exp  -4-  pred. 

Therefore,  in  the  cc^dep  rule  because  we  have  x  G  FV(5)  it  must  be  that  A  is  one  of  the  above 
mentioned  types,  none  of  which  can  contain  placeholder  variables.  Therefore  we  can  omit  the  check 
PVF(A). 

Similarly  we  infer  that  any  object  N  of  type  exp,  pred  or  exp  pred  can  only  contain  variables 
of  type  exp.  We  deduce  therefore  that  the  condition  p  =  full  D  PVF(r(x))  is  always  satisfied  in 
the  rule  cc_x  and  can  be  omitted. 

The  reasoning  behind  these  optimizations  depends  only  on  the  syntactic  structure  of  expressions 
and  predicates  and  on  the  fact  that  the  only  dependent  type  is  that  of  proofs.  It  is  reasonable  to 
expect  that  these  properties  hold  for  a  very  large  class  of  first-order  logics,  and  therefore  the 
optimizations  presented  here  are  not  specific  to  C  but  can  be  applied  to  many  other  first-order 
logics. 
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Main  Reconstruction  : 


T,x:A^M:B 


-tp_lam 


r  f  Xx.M  :  Ux:A.B 
rf  M=4>(A;C;S)  T,  A  F  5  =i>  Dom{A)  C  Dom{<i>) 


TtM:A^^ 


Dom(T) 


tp_app 


M  is  not  an 
abstraction 


Constraint  Collection: 


p  =  full  D  PVF(r(.T)) 

r^x^i-;-:  r(x)) 

M  {A;  C  ;Ilx:  A.B)  p  ^  full 
r^M*^{A,u^:A;C-,[u’^/x]B) 

r  f  M  {A  ]  C -yUx-.A.B)  linear {x,B)  p  ^  full 

T  M  *  {A,u^  :  A  ■,  C  ;  [u^/x]B) 

M  ^  {A-,C  ;Ilx:A.B)  xeFV{B)  PVF(^) 
T^MN^{A-,C,N  :,uii  A  ;  [N/x]B) 

r^M=>{A-,C;Ux:A.B)  x  ^  FV(5) 


-cc_x 


cc_linp 


cc^dep 


Constraint  Solving: 


FF  Cl,  (72,(73  ^’5' 


cc_indep 


FF 


-cs_0 


rFC2,Ci,C3=^^ 


cs_ord 


^(r)  F  ^(C)  ^^(r)  F  ^{C) 

- CS-tp  - _  :y'-  - — : - - CS.Unif 


TfC.MipA^^'o^ 


Atomic  Unification: 


C^aC 

Normal  Unification 


au-C 


X  ^ 


-au_x 


M^M' 


rfC,AaaB^^'o^ 

M  M'  ^  ^{N)  «  ^(JV') 

M  iV  M'  iV'  O 


^  M  M'  ^ 

-u-lam  — — - - ^u_at 


au_app 


Xx.M  a  Xx.M' 

Nonlinear (Nj)  [^„(iV„)/x„] . . .  [^i(Ari)/a;i]M  M'  =>  9' 

{Xxi. . . .  Xxn-M)  ATj  . . .  jV„  «a  M'  o  o  . . .  o 


u_beta 


u  ^  FV(M)  Nonlinear  (M)  =>  ^ 

u_linst  - f; - tt — — t: — r-n - r-pi - u_inst 


^M  ^M  u"  «  M  ^  ^  o  [n”  ■«-  M] 

Figure  16:  The  optimized  type  reconstruction  algorithm 
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10  The  Implementation  of  Type  Reconstruction 


In  this  section  we  present  the  main  implementation  techniques  that  we  currently  use  in  the  imple¬ 
mentation  of  the  type  reconstruction  shown  in  Figure  16  on  the  previous  page.  We  touch  issues 
ranging  from  efficient  implementation  of  A  calculi  to  memory  management  and  a  portable  and 
compact  binary  representation.  For  each  implementation  choice  we  describe  how  it  affects  the  type 
reconstruction  algorithm. 

With  the  implementation  techniques  described  here  we  were  able  to  obtain  efficient  proof  check¬ 
ing  and  maintain  the  size  of  the  proof  representation  at  reasonable  levels,  as  shown  in  Section  11. 
However,  our  efforts  in  this  area  were  limited  and  we  therefore  believe  that  more  can  be  done 
towards  smaller  representations  and  faster  proof  validation. 

10.1  De  Bruijn  Notation  and  Explicit  Substitutions 

In  the  abstract  presentation  of  the  type  reconstruction  algorithm  we  assumed  certain  meta¬ 
properties  of  variables  and  substitutions  such  as  term  identity  modulo  renaming  of  bound  vari¬ 
ables  and  capture-avoiding  substitutions.  A  concrete  implementation  must  deal  with  these  issues 
explicitly.  The  essence  of  our  implementation  choices  is  best  modeled  abstractly  by  a  normal-form 
variant  of  the  Xa  calculus  with  explicit  substitutions  and  De  Bruijn  indices  as  presented  in  [1]. 
However,  the  presence  of  type  reconstruction  makes  our  implementation  more  complex  than  the 
one  suggested  by  [1]. 

For  the  implementation  of  bound  variables  we  use  De  Bruijn[2]  indices.  In  such  an  imple¬ 
mentation  each  bound  variable  is  represented  as  a  positive  integer.  In  this  representation  the  De 
Bruijn  index  n  denotes  the  variable  bound  by  the  enclosing  A-abstraction.  Also,  in  such  a 
representation  there  are  variable  names  and  the  abstractions  are  denoted  simply  by  the  symbol  A. 

The  De  Bruijn  notation  captures  the  essence  of  a  term  without  regard  to  irrelevant  details  such 
as  bound  variable  names.  Thus  a-equivalence  is  obtained  directly  by  representation.  For  example, 
both  Xx.Xy.,xy  and  Xy.Xx.yx  have  the  same  De  Bruijn  representation,  namely  AA21. 

Although  the  De  Bruijn  notation  is  not  easily  readable  it  leads  to  simple  implementations.  A 
more  serious  disadvantage  of  the  De  Bruijn  notation  is  that  implementing  substitution  becomes 
more  complex.  For  example  in  order  to  perform  the  substitution  [M/x]N  it  is  not  sufficient  to 
substitute  M  for  x  in  N.  Consider  the  situation  where  there  are  occurrences  of  x  in  an  abstraction 
contained  in  N.  The  correct  procedure  in  this  case  is  to  increase  by  one  all  De  Bruijn  indices  from 
M.  Similar  difficulties  occur  with  /3-reduction. 

Another  problem  that  we  must  face  when  implementing  the  type  reconstruction  is  the  imple¬ 
mentation  of  substitution.  We  mentioned  before  the  complications  due  the  interaction  between  sub¬ 
stitution  and  bound  variables.  In  addition,  the  direct  implementation  of  the  substitution  [M/x]N 
is  expensive  because  it  involves  copying  the  term  M  for  each  occurrence  of  rr  in  iV  and  in  most 
cases  most  of  the  term  N  must  be  copied  also.  This  causes  a  size  explosion  and  excessive  memory 
usage  unless  sophisticated  structure-sharing  mechanisms  are  used  [20]. 

We  chose  to  perform  substitution  in  a  lazy  fashion,  postponing  a  substitution  until  we  come 
across  a  substituted  variable.  At  that  point,  we  lookup  the  substitution  and  we  continue  our  current 
operation  on  the  body  of  the  substitution.  Such  an  implementation  is  modeled  very  closely  by  the 
Act  calculus  of  explicit  substitutions  [1]. 

Our  variant  of  the  Act  calculus  is  slightly  more  complicated  than  that  presented  in  [1]  because 
we  want  it  to  model  closely  our  implementation  of  unification.  On  the  other  hand,  during  type 
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reconstruction  all  the  terms  are  preserved  in  normal  form  and  therefore  our  variant  uses  only  one 
substitution  operator. 

We  present  next  the  syntax  of  the  Xa  calculus  and  proceed  then  to  show  how  it  is  used  in  the 
implementation  of  the  type  reconstruction  algorithm.  See  [1]  for  formal  results  about  the  adequacy 
of  the  calculus  for  implementing  dependent-typed  A  calculus. 

At  the  level  of  syntax  we  replace  variables  with  De  Bruijn  indices,  we  change  the  formal  of  term 
and  type  abstraction  accordingly  and  we  also  introduce  a  distinguished  term  constant  *.  Explicit 
substitutions  are  a  sequence  of  locations  whose  values  are  given  by  a  state.  As  the  terminology 
suggests,  this  indirection  is  exposed  because  we  desire  to  model  the  side-effects  of  unification.  This 
is  the  main  complication  added  to  the  traditional  Act  calculus.  The  syntax  is  summarized  in  the 
table  below: 


Terms  M 

Types  A 

Locations  I 

Substitutions  s 
State  fi 


n  I  c  I  *  I  Ml  M2  I  AM 
a  I  AM  I  UA.B 


•  I  I  •  s 

•  I  0,/^M{s} 


In  preparation  for  the  discussion  of  how  the  type  reconstruction  rules  are  infiuenced  by  the 
explicit  substitutions  we  find  it  useful  to  give  a  few  concrete  implementation  details.  Note  that 
substitutions  as  defined  by  the  syntax  above  are  just  lists.  In  fact  they  are  implemented  as  lists. 
Locations  are  just  names  (implemented  as  pointers)  for  the  car  fields  of  lists.  The  substitution  state 
is  implemented  by  the  computer  memory  by  storing  the  corresponding  values  in  the  appropriate 
car  cells. 

For  example,  the  transition  from  substitution  s  in  state  Q  to  substitution  /  •  5  in  state  1  ^ 
M{s'}  is  implemented  by  consing  a  new  list  cell  to  the  list  s  and  storing  in  the  car  field  the  values 
M  and  5'.  We  note  here  that  each  list  cell  is  in  fact  3  memory  words.  Keep  in  mind  also  that  there 
is  a  significant  amount  of  sharing  among  the  lists  and  that  changing  the  contents  of  a  substitution 
location  does  affect  many  terms. 

We  do  not  show  here  the  complete  description  of  the  reconstruction  algorithm  in  the  presence  of 
explicit  substitutions.  Instead  we  give  some  general  rules  that  govern  the  manipulation  of  explicit 
substitutions  and  we  exemplify  them  by  showing  the  new  version  of  unification. 


As  a  general  rule,  in  the  new  version  of  the  algorithm  all  types  and  terms  occurring  in  judgments 
are  accompanied  by  a  substitution  object  that  records  all  delayed  substitutions  for  that  particular 
term  or  type.  We  write  M{s}  to  denote  that  the  substitution  s  corresponds  to  the  term  M.  During 
type  reconstruction  the  pair  of  a  term  and  substitution  is  always  closed.  For  example,  if  the  term 
M  contains  n  free  variables,  then  it  is  always  accompanied  by  a  substitution  that  is  at  least  of 
length  n.  Then  the  free  variable  with  index  1  in  M  refers  to  the  top  of  the  substitution  list,  index 
2  refers  to  the  second  element,  and  so  on.  This  means  that  the  pair  l{/i  •  s}  represents  the  same 
term  as  the  one  bound  to  li  in  the  current  state.  Similarly  the  term  2{li  -h-s}  represents  the  term 
bound  to  I2  in  the  current  state. 

Another  general  rule  is  that  all  the  judgments  have  a  potential  side-effect  on  the  substitution 
state.  Thus  all  the  judgments  are  changed  to  take  a  state  in  input  (written  usually  at  the  left  of 
the  I-  symbol)  and  return  a  new  state  value  (written  at  the  right  end  of  the  judgment,  usually  after 
a  =>  symbol). 

As  an  introduction  to  explicit  substitution  in  the  indirect  form,  we  show  how  the  ^-reduction  rule 
would  be  implemented.  For  a  gentler  introduction  and  formal  correctness  proofs  see  [1].  Consider 
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that  the  current  substitution  state  is  and  the  /3-redex  is  {XM)N  accompanied  by  the  substitution 
s.  The  /3-reduction  rule  is  shown  below: 

h  {\M)N{s}  M{1  •  s}  I  is  new  to  0, 

This  rule  is  actually  very  close  to  the  actual  implementation.  In  order  to  perform  (^-reduction  we 
cons  to  *■  a  new  list  cell  and  let  I  be  the  address  of  the  new  car  field.  Then  we  store  the  term  N 
accompanied  by  its  substitution  in  the  car  field  and  return  the  resulting  substitution  together  with 
M. 

As  wo  can  see  the  immediate  cost  of  performing  the  /0-reduction  is  very  small.  The  hidden 
cost  of  //-reduction  surfaces  when,  during  the  processing  of  the  result,  we  encounter  the  substituted 
variabh'.  or  more  precisely  its  De  Bruijn  index.  At  this  point  we  must  lookup  the  substitution  paired 
with  th('  term  and  continue  with  the  processing  of  the  substituted  term.  As  a  general  rule,  this 
lookup  ()])('ration  is  performed  whenever  the  term  is  a  variable,  possibly  multiple  times  in  sequence. 
The  following  two  rules  describe  this  lookup  operation  as  a  judgment  12  h  M{s}  =  M'{s'}  12'. 

Ignore  for  a  moment  the  side-condition  on  the  second  lookup  rule. 

12  b  n{s}  =  M’{s'}  =»  12'  n{l)  +  *{•}  12  h  12(0  =  =»  12' 

Q  h  n  -1-  1{Z  •  s}  =  Af'{s'}  O'  Oh  !{/  •  s}  =  M'  {s'}  ^  O' 

Focusing  on  unification  we  extend  the  above  equality  judgment  with  one  that  incorporates  a 
not  ion  of  weak  head  reduction.  This  means  that  enough  /3  redices  are  reduced  so  that  an  abstraction 
or  an  ai)i)lication  with  the  head  either  a  constant  or  a  variable  is  exposed.  The  following  rule 
d(>.scrib(!s  the  weak  head  reduction.  Notice  in  the  second  hypothesis  an  instance  of  the  /3  reduction 
rul('  pr(!sented  above. 


il  h  Mi{s}  =  =»  n'  12',/  ^  M2{s}  h  M}{1  ■  s'l}  =  M'{s'}  =>  12" 

12  h  Ml  M2{s}  =  M'{s'}  12" 


I  is  new  to  12' 


After  the  unification  judgment  reduces  both  terms  involved  according  to  the  equality  relation 
defined  above  the  resulting  terms  are  matched  according  to  the  unification  relation  defined  below. 
Consider  the  case  when  the  resulting  terms  are  both  abstractions. 


12,  /i  i-  c{-},  I2  <—  c{-}  \-  M{li  ■  s}  ^  M'{l2  •  5'}  =»  12'  /i  and  I2  are  new  to  12 
12  H  XM{s}  «  AM'{s'}  12'  c  is  a  new  constant 

In  this  case  both  abstractions  are  opened  with  the  bound  variable  substituted  by  a  newly 
generated  constant.  This  trick  helps  preserve  the  invariant  that  all  terms  are  closed  and  also 
ensures  that,  down  the  road,  when  we  compare  two  instances  of  the  bound  variable,  the  unification 
succeeds  with  the  constant  unification  rule.  Note  that  we  allocate  two  new  locations  to  which  we 
assign  the  same  value  and  not  just  one.  This  decision  is  with  an  eye  to  the  implementation  of 
substitutions  as  lists.  In  such  an  implementation  we  cannot  cons  the  same  cell  to  two  different  lists. 
Exactly  the  same  procedure  is  followed  whenever  an  abstraction  is  opened. 

Next  we  have  the  instantiation  rule.  We  ignore  here  the  details  of  atomic  versus  normal  unifi¬ 
cation  and  of  the  occurs  check  optimization. 


f2(/)  =  *{-}  l^M'{s'} 

12  h  !{/  •  s}  «  M'{s']  =>  12,  /  ^  M'{s'} 


I  is  new  to  12 
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First  note  that  the  instantiation  does  not  work  on  the  term  *{•}  but  on  1{/}  where  I  currently 
has  the  placeholder  value.  This  is  because  the  essence  of  the  instantiation  is  to  side-effect  the 
state  by  changing  the  value  associate  with  the  location  1.  In  fact  this  does  not  explicitly  collect  a 
substitution  but  immediately  performs  it  on  all  the  terms  of  the  current  reconstruction,  and  all 
this  with  just  a  memory  store.  Note  that  the  occurs  check  verifies  that  the  term  does  not 

contain  I  and  therefore  the  unification  does  not  lead  to  circularity. 

Finally  we  have  the  unification  rule  for  application. 

Q  h  M{s}  O'  O'  h  N{s}  «  N{s'}  =>  0" 

0  h  M  N{s}  M'  N'{s'}  =>  0" 

We  notice  here  that  we  do  not  have  to  perform  the  expensive  substitutions  ^  {N)  and  ( W')  or 
the  substitution  composition.  All  these  are  taken  care  of  in  the  instantiation  rules  and  are  recorder 
in  the  substitution  state. 

This  ends  our  implementation  sketch.  Even  though  we  only  discussed  the  unification,  all  the 
other  judgments  apply  exactly  the  same  techniques  for  manipulating  the  explicit  substitutions. 

10.2  Implementing  the  Occurs  Check  Optimization 

The  occurs  check  optimization  presented  in  Section  9  uses  the  notion  of  linear  placeholder  variables 
and  the  function  nonlinear.  In  the  actual  implementation  the  linearity  attribute  is  not  attached 
to  the  placeholder  itself  but  to  the  location  that  contains  its  instantiation.  For  this  purpose  we 
extend  the  syntax  of  explicit  substitutions  with  the  notion  of  linear  and  non-linear  locations.  As 
locations  are  introduced  in  the  collecting  rule  they  are  labelled  in  a  similar  way  to  the  placeholder 
variables. 

This  setup  permits  a  very  efficient  implementation  of  the  function  Nonlinear  used  in  the  instan¬ 
tiation  rule  u_inst  and  in  the  rule  u_beta.  Instead  of  computing  the  Nonlinear  function  eagerly 
we  just  reset  the  linearity  attribute  of  the  variables  u  in  the  u_inst  rule  or  x  in  the  uJbeta  rule  are 
non-linear. 

The  linearity  attribute  of  a  location  is  used  during  unification  in  the  following  manner.  The 
implementation  of  unification  maintains  a  boolean  flag  that  says  whether  an  occurs  check  must  be 
made  when  an  instantiation  is  performed.  The  flag  is  initially  false  and  is  set  to  true  whenever  the 
unification  unrolls  a  substitution  corresponding  to  a  non-linear  location.  Finally,  an  occurs  check 
is  made  for  every  instantiation  that  happens  when  the  flag  set  to  true. 

With  this  implementation,  everything  that  is  substituted  for  a  non-linear  placeholder  variable 
is  treated  as  non-linear,  without  having  to  compute  the  Nonlinear  substitution.  As  an  additional 
benefit  this  implementation  indirectly  achieves  a  new  occurs  check  optimization.  The  first  time  a 
non-linear  location  is  instantiated  no  occurs  check  is  made.  However  if  unification  ever  crosses  the 
same  location  again,  it  sets  the  occurs  check  flag  so  that  all  variables  that  were  substituted  for  the 
non-linear  placeholder  variable  behave  as  if  they  were  non-linear. 

Thus  explicit  substitutions  not  only  help  amortize  the  cost  of  performing  substitutions  but  prove 
to  be  excellent  vehicles  for  implementing  the  occurs  check  optimization. 

10.3  Memory  Management 

One  of  the  main  advantages  of  using  explicit  substitutions  is  that  the  memory  footprint  of  the 
reconstruction  algorithm  is  very  small.  The  only  memory  allocation  required  is  for  the  substitution 
lists.  In  our  implementation  this  amounts  to  3  words  for  each  substitution  performed. 
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Moreover  if  no  instantiation  is  performed  while  checking  a  subterm  then  the  only  modification 
to  the  state  is  allocation  and  the  entire  memory  allocated  for  checking  that  subterm  can  be  deal¬ 
located.  In  such  a  situation  the  memory  usage  follows  a  stack  pattern.  To  exploit  this  pattern  our 
implementation  contains  a  stack-based  memory  allocator.  Whenever  we  start  processing  a  subterm 
we  place  a  marker  on  the  allocator’s  stack.  When  we  are  done  with  that  subterm  we  deallocate  at 
once  all  the  memory  used  while  checking  the  current  subterm.  This  implementation  achieves  very 
fast  memory  allocation  and  deallocation  and  also  has  good  cache  locality. 

However,  if  we  are  doing  reconstruction  and  not  just  checking  fully-explicit  terms  then  there  can 
be  side-effects  to  the  state.  Because  instantiations  create  sharing  relationships  between  substitution 
locations  it  is  not  correct  in  general  to  deallocate  all  the  memory  used  while  processing  a  subterm. 

In  order  to  identify  the  situations  when  we  can  still  safely  deallocate  memory  the  implementation 
of  unification,  goal  solving  and  type  checking  keep  track  of  how  many  distinct  placeholder  variables 
are  in  the  type  environment  T  and  in  the  type  A  to  be  verified.  The  counter  is  incremented  with 
each  placeholder  variable  introduced.  The  counter  is  decremented  with  each  instantiation.  Note 
that  it  is  not  possible  for  two  distinct  instantiations  to  instantiate  the  same  placeholder  variable. 
Using  this  simple  counter  we  can  conservatively  detect  the  situations  when  no  instantiation  will 
happen  during  the  processing  of  a  subterm  because  there  are  no  placeholder  variables.  In  these 
situations  we  deallocate  memory. 

This  memory  optimization  is  fairly  conservative  because  it  fails  to  deallocate  when  there  are 
placeholder  variables  but  none  is  instantiated.  In  these  situations  the  memory  deallocation  is 
delayed  until  all  the  current  placeholders  are  instantiated.  This  eventually  happens  because  at 
the  top  level  there  are  no  placeholders.  Even  such  a  conservative  implementation  performs  well  in 
practice  as  shown  in  Section  11. 

10.4  The  Flat  Binary  Representation 

The  last  implementation  detail  that  we  present  here  is  the  actual  representation  of  the  syntax  of 
LF  terms  and  types.  There  are  four  main  classes  of  terms:  variables,  constants,  applications  and 
abstractions.  For  the  purpose  of  representation  we  ignore  the  difference  between  a  terms  and  types. 

The  basic  representation  cell  is  32  bits  and  has  the  following  bit  structure: 


LENGTH 


DATA 


TAG 


31  16  30 


Figure  17:  The  basic  representation  cell. 

The  tag  field  distinguishes  between  a  variable,  a  constant,  an  application  or  an  abstraction.  All 
the  4  tag  values  are  odd  because  we  reserve  cells  with  even  values  to  represent  pointers  to  other 
representation  cells. 

In  the  case  of  a  variable  the  data  portion  contains  the  De  Bruijn  index  of  the  variable.  In 
the  case  of  a  constant  the  data  consists  of  an  index  into  the  signature  table.  The  length  field  for 
variables  and  for  constants  is  always  4  because  they  occupy  only  one  cell. 

An  application  Mq  Mi  . . .  Mn  is  represented  as  a  representation  cell  with  an  application  tag, 
the  data  value  equal  to  n  +  1  (to  the  number  of  terms  in  the  application)  and  followed  by  the 
representations  of  for  i  =  0, . . . ,  n.  The  length  field  for  the  application  is  equal  to  the  number  of 
bytes  used  to  represent  the  entire  application  term  including  its  subterms.  This  value  is  redundant 
but  it  is  used  to  speed  up  the  breadth-first  scanning  of  terms. 
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An  abstraction  Xxi  :Ai.Xx2  :  A2 _ Xxn  is  represented  as  a  representation  cell  with  an 

abstraction  tag,  the  data  field  equal  to  n  +  1  and  the  length  field  equal  to  the  length  of  the  entire 
abstraction.  This  cell  is  followed  in  order  by  the  representations  of  for  i  =  1, , . . ,  n  and  then  by 
the  representation  of  M. 

For  example,  we  show  in  Figure  18  the  actual  representation  of  the  term  ci  C2  {Xx:a.c^  x). 


32 

APP 

4 

4 

C2 

20 

0 

S9V 

4 

□ 

12 

1 

2 

APP 

4 

C3 

4 

1 

% 

> 

Figure  18:  The  flat  representation  of  the  term  M  =  Ci  C2  (Aa;:a.C3  x).  The  labels  Ci  and  a  stand 
for  integer  indices  into  the  signature  table. 

The  main  characteristic  of  this  representation  is  that  it  avoids  the  use  of  pointers.  For  this 
reason  the  representation  is  compact  and  has  good  spatial  locality  of  reference.  Most  of  the  time 
the  terms  are  scanned  depth-first  exactly  in  the  order  they  are  laid  out  in  memory  .  In  the  rare 
cases  when  this  does  not  happen  the  length  field  allows  for  efficient  skipping  of  subterms. 

Due  to  the  flatness  of  representation  it  is  not  possible  to  share  subterms,  and  thus  a  size 
explosion  occurs  if  a  subterm  has  many  instances  in  the  representation.  This  situation  does  not 
occur  often  in  our  experiments,  mainly  because  we  do  not  perform  substitution  eagerly.  However, 
there  is  one  proviso  to  the  representation  rules  that  allow  for  sharing.  If  the  low-order  bit  of  the 
tag  is  zero,  the  the  content  of  the  representation  cell  is  a  pointer  to  a  subterm.  For  this  reason  we 
select  odd  values  for  the  variable,  constant,  application  and  abstraction  tags  and  we  reserve  the 
even  value  to  signal  indirection. 

The  binary  representation  can  be  made  even  smaller  because  most  of  the  time  the  data  field 
uses  significantly  less  than  13  bits,  and  also  because  the  length  field  is  redundant.  However,  we 
keep  the  representation  cells  32-bit  long  because  we  occasionally  want  to  fit  machine  pointers  in 
them  and  also  due  to  alignment  constraints  on  the  physical  machines  we  use. 

However,  these  justification  do  not  apply  to  an  external  representation  of  LF  terms,  on  the  file 
system  or  in  the  network  for  example.  The  external  representation  is  very  similar  to  the  internal 
representation  with  the  difference  that  the  cells  do  not  contain  a  length  field  and  are  only  16-bit 
long.  In  the  external  representation  the  indirection  pointers  are  replaced  with  even  indices  into  an 
indirection  table  that  accompanies  the  LF  term.  The  length  field  is  easily  re-generated  when  the 
external  representation  is  converted  to  the  internal  form. 
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11  Performance  Measurements 


In  this  section  we  compare  the  implicit  LF  representations  obtained  using  the  three  erasure  algo¬ 
rithms  presented  in  Section  7  among  themselves  and  with  the  fully-explicit  representation.  The 
parameters  that  we  measure  for  each  representation  are  the  size,  the  reconstruction  time  and 
the  dynamically  allocated  memory  required  for  reconstruction.  Then,  we  conclude  the  performance 
analysis  with  the  presentation  of  the  benefits  gained  using  the  optimizations  presented  in  Section  9. 

The  data  set  used  for  the  measurements  presented  in  this  report  is  obtained  from  our  case 
studies  of  Proof-Carrying  Code  (PCC)  [12].  PCC  is  a  technique  that  a  server  can  use  to  ensure 
with  absolute  certainty  that  the  code  provided  by  an  untrusted  client  is  safe  to  run,  for  a  previously 
defined  notion  of  safety.  The  idea  behind  PCC  is  that  the  client  provides,  together  with  the  code, 
the  LF  repres(Mitatioii  of  a  formal  proof  of  safety.  In  the  context  of  PCC  it  is  important  for  the 
proof  represinitations  to  be  small  because  they  accompany  the  code  and  it  is  also  important  for  the 
reconstruction  to  lx*  fast  because  it  is  executed  by  the  server  in  the  critical  path. 

We  extract ('(1  the  PCC  safety  proof  for  32  experimental  programs  written  in  the  DEC  Alpha 
assembly  languag(\  These  programs  include  several  variants  of  network  packet  filters  [14],  several 
variants  of  th(‘  IP  clu^cksum  routine  [13]  and  other  PCC  experiments  presented  in  [13].  The  sizes 
of  these  programs  range  from  10  to  50  assembly  language  instructions.  In  all  the  experiments 
considered  in  this  report  the  LF  objects  to  be  reconstructed  are  implicit  representations  of  proofs 
in  first-order  logics  similar  to  the  logic  C  presented  in  Section  2. 

For  each  of  tlu'  32  proofs  we  considered  four  representations.  The  basic  representation  is  the 
fully-explicit  oik'.  We  conjecture  that  the  performance  of  the  type-reconstruction  algorithm  on 
explicit  representations  is  a  good  estimate  of  the  cost  of  LF  type-checking  because  there  is  a  close 
similarity  between  the  number  and  the  nature  of  the  operations  performed  in  both  cases.  The 
other  three  representations  that  we  consider  are  those  obtained  through  the  local,  one-bit  global 
and  global  erasures  from  the  explicit  representations. 

All  the  size  measurements  are  of  the  binary  representation  of  LF  terms,  as  presented  in  Sec¬ 
tion  10.4.  Recall  that  all  LF  constants  are  represented  as  indices  into  the  signature  table.  We 
include  in  the  size  of  the  representation  the  size  of  the  linkage  information,  which  is  a  list  of  the 
constant  names  in  the  signature.  The  linkage  table  is  only  required  if  there  is  no  preestablished 
order  of  individual  constants  in  the  signature.  If  we  omit  the  size  of  the  linkage  table,  the  results 
presented  in  the  rest  of  this  section  are  improved. 

The  size  of  the  explicit  representation  serves  as  the  basis  of  evaluation  for  the  erasure  algo¬ 
rithms.  For  each  of  the  implicit  representations  we  measure  the  improvement  in  the  reconstruction 
time  and  the  size  of  the  dynamically  allocated  memory  used  during  type  reconstruction.  All  the 
measurements  were  done  on  a  DEC  Alpha  workstation  with  a  175-MHz  Alpha  21064  processor  and 
a  2-Mbytes  board-level  cache.  The  measurements  are  performed  with  a  warm  cache  and  we  average 
the  data  over  at  least  consecutive  1000  runs. 

Table  3  shows  absolute  performance  data  for  the  fully-explicit  representation  and  the  one-bit 
global  representation.  We  only  show  in  this  table  only  a  handful  of  representative  cases.  The 
experiment  entitled  Cap  is  the  resource  access  service  from  [14].  The  packet  filters  3  and  4  are  also 
described  in  [13].  The  Ping  experiment  is  the  largest  PCC  experiment  to  date  and  involves  checking 
both  safety  and  liveness  properties  of  a  simple  implementation  of  the  ping  network  protocol.  The 
experiment  Safe  ML  is  described  in  [12].  In  the  rest  of  this  section  we  shall  focus  on  relative 
performance  comparisons.  All  the  reported  results  are  based  on  32  experiments  that  include  all 
those  described  here  and  others  that  are  similar  but  generally  smaller. 

In  order  to  compute  the  reduction  in  the  representation  size  and  reconstruction  time,  we  com- 
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Experiment 

Explicit 

One-bit  Global 

Size 

(bytes) 

Rec.  Time 
(ms) 

Rec.  Heap 
(bytes) 

Size 

(bytes) 

Rec.  Time 
(ms) 

Rec.  Heap 
(bytes) 

Cap 

3049 

7.41 

5896 

257 

1.14 

4984 

IP  Checksum 

23198 

56.84 

20088 

1037 

5.77 

15432 

Packet  Filter  3 

15898 

36.75 

17648 

561 

2.80 

13136 

Packet  Filter  4 

14502 

33.57 

15016 

547 

2.60 

10216 

Ping 

181527 

458.27 

53376 

4149 

24.86 

38928 

Safe  ML 

13758 

34.72 

12152 

707 

4.30 

11144 

Tal)l(*  3:  Absolute  performance  data  for  the  type  reconstruction  of  fully-explicit  and  one-bit  global 
r(*pn‘s(aitations. 


put(‘  t  li(*  geometric  means  of  corresponding  ratios.  The  resulting  values  are  shown  in  Table  4.  Based 
on  results  we  conclude  that  all  implicit  representations  achieve  significant  reductions  in  the 

si/<‘  of  r('j)resentation  and  the  validation  time.  The  memory  required  for  validation  is  reduced  by 
only  ai)proximately  35%.  Such  a  small  improvement  in  memory  usage  is  motivated  by  the  fact  that 
tli(‘  inor(‘  implicit  the  representation,  the  more  memory  is  required  for  holding  the  reconstructed 
subt('nns.  and  the  fewer  opportunities  to  deallocate  memory  eagerly  (see  the  description  of  the 
iiKMiiory  optimization  in  Section  9). 

Th('  major  surprise  revealed  by  the  data  from  Table  4  is  that  the  global  representation  algorithm 
is  not  significantly  more  effective  than  the  one-bit  global  algorithm  in  terms  of  representation  size 
and  n'construction  time.  In  addition,  it  increases  slightly  the  amount  of  memory  required  for 
rc'construction.  The  main  reason  for  such  a  dismal  improvement  over  the  one-bit  algorithm  is  that 
th('  one-bit  erasure  succeeds  in  removing  the  vast  majority  of  redundant  subterms  and  achieves  a 
luiar  oi^timal  representation,  leaving  very  little  room  for  improvement.  Interestingly,  the  one-bit 
global  erasure  algorithm  achieved  optimal  results  on  the  largest  experiments  we  performed.  These 
observation,  combined  with  the  substantial  complexity  of  the  global  erasure  algorithm,  lead  to  the 
conclusion  that  the  global  erasure  algorithm  is  not  of  practical  value  for  the  implicit  representation 
of  first-order  proofs. 


Ratio 

Local 

One-bit 

Global 

Representation  size 

5.08 

15.42 

15.83 

Reconstruction  time 

3.71 

7.71 

7.81 

Reconstruction  space 

1.31 

1.36 

1.32 

Table  4:  The  reduction  in  representation  size,  reconstruction  time  and  space  due  to  the  implicit 
representation. 

While  the  ratios  shown  in  Table  4  clearly  demonstrate  the  effectiveness  of  the  implicit  repre¬ 
sentations  for  first-order  logic  proofs,  they  do  not  show  the  whole  power  of  reconstruction.  We 
observed  that  the  improvements  due  to  implicit  representations  are  larger  in  relative  terms  as  the 
proofs  get  larger.  This  suggests  that  a  simple  ratio  does  not  convey  the  true  performance  benefit 
to  be  gained  through  reconstruction. 
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Figure  19:  The  representation-size  reduction  as  a  function  of  the  explicit  representation  on  loga- 
rithmic  scale. 
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Figure  20:  The  reconstruction-time  reduction  as  a  function  of  the  explicit  reconstruction  on  loga¬ 
rithmic  scale. 
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In  Figure  19  and  20  we  plot  on  logarithmic  scale  the  improvement  ratios  of  the  representation 
size  and  the  validation  time  as  a  function  of  the  explicit  representation  size  and  reconstruction 
time,  for  the  32  experiments  considered.  These  figures  show  that,  at  least  for  the  one-bit  global 
representation,  the  improvements  are  superscalar.  We  have  computed  logarithmic  correlations  of 
the  implicit  and  explicit  values  of  the  representation  size  and  the  reconstruction  time.  The  results 
suggest  that,  for  the  local  erasure,  the  improvements  are  scalar  and  are  accurately  described  by  the 
simple  ratios  shown  in  Table  4.  For  the  one-bit  global  erasure,  however,  we  have  found  that  the 
following  formulas  are  more  accurate  for  the  range  of  term  sizes  covered  by  our  experiments: 

One-bit  size  =  2.03  *  Explicit  size^'^^  with  a  correlation  of  0.94 

One-bit  time  =  1.81  *  Explicit  time^'^*^  with  a  correlation  of  0.95 

These  formulas  suggest  that  as  the  size  of  the  problem  increases,  the  improvement  ratio  of  the 
one-bit  global  representation  compared  to  the  fully-explicit  representation  also  increases.  More 
experiments  with  large  LF  terms  are  required  to  substantiate  these  findings. 

11.1  Effectiveness  of  Optimizations 

The  results  of  the  previous  section  are  obtained  with  all  the  optimizations  presented  in  Section  9. 
In  the  rest  of  this  section  we  show  our  findings  regarding  the  effectiveness  of  these  optimizations.  To 
evaluate  an  optimization  we  measure  the  reconstruction  time  and  space  with  only  that  optimization 
disabled  and  then  with  all  the  optimizations  enabled,  for  the  four  LF  representations.  We  then 
compute  the  geometric  mean,  over  the  32  experiments,  of  the  ratio  between  the  optimal  value  of 
the  performance  parameter  and  the  value  with  the  optimization  disabled.  We  report,  in  Table  5 
and  6,  the  result  of  subtracting  from  100%  the  mean  ratio  for  the  reconstruction  time  and  space 
respectively.  A  value  of  10%  in  these  tables  means  that,  on  the  average,  the  optimization  reduces 
the  reconstruction  time  or  space  to  90%  of  the  original  value. 


Optimization 

Explicit 

Local 

One-bit 

Global 

Occurs  Check 

0.07% 

24.23% 

43.75% 

43.88% 

Memory  Management 

-1.46% 

-0.59% 

-0.44% 

0.11% 

Side-Condition 

13.62% 

8.90% 

1.73% 

1.96% 

First-Order  Logic 

8.51% 

5.40% 

0.94% 

1.72% 

All 

15.91% 

30.49% 

44.16% 

44.71% 

Table  5:  The  effect  of  the  optimizations  on  the  reconstruction  time.  Each  value  is  obtained  by 
subtracting  from  100%  the  geometric  mean  over  32  experiments  of  the  ratio  between  the  optimal 
time  and  the  time  with  one  optimization  disabled. 

We  notice  that  the  occurs  check  optimization  has  a  major  effect  on  the  reconstruction  time  and 
it  is  more  eflfective  for  the  representation  with  more  implicit  subterms.  This  is  because  the  occurs 
check  is  only  required  for  the  instantiation  of  implicit  subterms.  The  occurs  check  optimization  has 
also  a  minor  improvement  on  the  memory  used  during  reconstruction,  because  it  avoids  memory 
allocation  that  is  normally  part  of  the  occurs  check. 

The  occurs  check  is  one  of  the  most  expensive  operations  performed  during  type  reconstruction. 
To  assess  the  cost  of  occurs  check  for  type  reconstruction  we  measured  the  reconstruction  time  for 
each  of  the  four  LF  representations  in  three  separate  circumstances:  with  the  occurs  check  turned 
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Optimization 

Explicit 

Local 

One-bit 

Global 

Occurs  Check 

0.00% 

0.64% 

0.77% 

0.77% 

Memory  Management 

88.92% 

66.91% 

35.56% 

35.86% 

Side-Condition 

3.96% 

0.00% 

0.00% 

0.00% 

First-Order  Logic 

0.00% 

0.00% 

0.00% 

0.00% 

All 

88.99% 

67.12% 

36.04% 

35.35% 

Table  6:  The  effect  of  the  optimizations  on  the  reconstruction  space.  Each  value  is  obtained  by 
subtracting  from  100%  the  geometric  mean  over  32  experiments  of  the  ratio  between  the  optimal 
space  and  the  space  with  one  optimization  disabled. 


off^,  with  it  turned  always  on  and  with  the  optimized  occurs  check  presented  in  Section  9.  In 
Table  7  we  show  for  each  representation  the  average  percentage  of  time  spent  doing  the  occurs 
check.  We  see  that,  in  the  unoptimized  case,  the  reconstruction  algorithm  spends  about  45%  of 
the  time  performing  the  occurs  check.  However,  with  the  simple  linearity  optimization  the  cost  of 
the  occurs  check  is  reduced  to  less  than  2%,  making  further  optimization  uninteresting. 


Parameter 

Explicit 

Local 

One-bit 

Global 

Cost  of  occurs  check 

0.09% 

24.70% 

44.28% 

44.67% 

Optimized  cost  of  occurs  check 

0.02% 

0.63% 

2.01% 

1.40% 

Table  7:  The  percentage  of  time  spent  doing  the  occurs  check,  in  the  unoptimized  and  optimized 
cases. 


The  memory  usage  optimization  has  a  major  effect  on  the  dynamically  allocated  memory  used 
during  reconstruction.  Recall  that  memory  deallocation  can  be  done  only  after  processing  a  subterm 
whose  type  contains  no  placeholder  variables.  The  more  implicit  the  representation,  the  more 
placeholder  variables  are  introduced  in  types.  This  explains  the  diminishing  effect  of  the  memory 
optimization  as  the  representation  becomes  more  implicit.  Even  so,  the  memory  usage  is  reduced 
by  approximately  35%  in  the  case  of  the  one-bit  global  representation.  Prom  the  viewpoint  of  the 
reconstruction  time,  the  deallocation  operation  increases  the  overall  running  time  by  about  0.44% 
for  the  one-bit  global  representation. 

The  side-condition  and  the  first-order  logic  optimizations  do  not  bring  significant  improvements 
in  the  reconstruction  space  and  time,  especially  in  the  case  of  the  implicit  representations.  Recall 
that  the  effect  of  these  optimizations  is  to  reduce  the  cost  of  checking  the  side-condition  when 
collecting  an  explicit  argument  that  occurs  in  the  result  type.  Such  arguments  are  reduced  to  a 
minimum  by  the  erasure  algorithms,  eliminating  the  opportunities  for  these  optimizations.  Never¬ 
theless  we  consider  that  these  optimizations  are  useful  because  they  reduce  the  complexity  of  the 
reconstruction  algorithm.  If  these  optimizations  are  applied  then  the  reconstruction  algorithm  does 
not  require  the  procedures  PVF(A)  and  the  more  complex  PVF(r(FV(iV)). 

In  addition  of  the  effect  of  individual  optimizations  we  also  measured  their  combined  effect.  For 
this  purpose  we  measured  the  reconstruction  time  and  space  with  all  the  optimizations  enabled  and 

^This  makes  reconstruction  unsound  but  is  useful  as  a  basis  for  performance  comparisons. 
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Figure  21:  The  correlation  between  the  ratio  of  the  optimized  reconstruction  time  to  the  time 
without  the  occurs  check  optimization  and  the  size  of  the  term. 
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Figure  22:  The  correlation  between  the  ratio  of  the  optimized  reconstruction  space  to  the  space 
without  the  memory  optimization  and  the  size  of  the  term. 
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then  with  them  disabled.  We  notice  that  with  all  the  optimizations  enabled  the  reconstruction  time 
is  reduced  by  44%  on  the  average  and  the  reconstruction  space  by  36%.  These  effects  are  mostly 
due  to  the  occurs  check  optimization  for  the  time  improvement  and  the  memory  optimization  for 
the  memory  usage  improvement. 

We  noticed  that  the  two  most  important  optimizations,  the  occurs  check  and  the  memory 
optimization,  have  the  tendency  to  achieve  better  improvements  for  larger  benchmarks.  We  plotted 
in  Figure  21  the  ratio  between  the  optimal  reconstruction  time  to  the  time  with  the  occurs  check 
optimization  disabled  as  a  function  of  the  term  size,  on  a  logarithmic  scale.  We  notice  on  the  graph 
that,  indeed,  the  occurs  check  optimization  becomes  more  effective  for  larger  terms.  A  similar 
and  more  pronounced  correlation  exists  between  the  effectiveness  of  the  memory  optimization  and 
the  size  of  the  term,  both  for  the  explicit  representation  and  the  one-bit  global  representation 
(Figure  22).  This  suggests  that  these  optimizations  are  more  effective  for  larger  terms  than  for 
small  ones,  although  more  large  experiments  are  required  to  ascertain  this  tendency. 

11.2  Correlation  between  the  Reconstruction  Time  and  Term  Size 

Although  not  directly  related  to  the  performance  of  the  erasure  algorithms  or  the  effectiveness 
of  optimizations,  we  briefly  discuss  the  relation  between  the  term  size  and  the  reconstruction 
time.  We  plot  in  Figure  23  this  correlation  for  the  explicit  representation  and  the  one-bit  global 
representation.  As  can  be  seen  from  the  figure,  in  our  current  experiments  involving  validation  of 
first-order  logic  proofs,  we  observe  a  linear  dependency  of  the  reconstruction  time  with  the  size  of 
the  proof  representation.  This  property  is  true  both  for  the  fully-explicit  representation  and  the 
one-bit  global  implicit  representation. 


Figure  23:  The  correlation  between  the  representation  size  and  the  reconstruction  time. 

These  results  are  not  possible  to  generalize  to  all  LF  reconstruction  tasks  because,  in  the 
worst  case,  the  complexity  of  the  reconstruction  is  superexponential.  This  is  hinted  by  the  fact 
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that  reconstruction  involves  /^-reduction  which  has  been  shown  by  Statman  to  be  not  elementary 
recursive  [19]. 

There  are  several  aspects  of  using  reconstruction  for  validating  first-order  logic  proofs  that 
suggest  a  better  behavior  that  in  the  general  case.  First,  the  reconstruction  algorithm  only  works 
on  canonical  terms.  Because  of  substitution  in  types  the  reconstruction  creates  /3-redices.  Such 
situations  occur,  in  the  context  of  first-order  logic,  only  when  checking  instances  of  rules  for  universal 
and  existential  quantification.  In  these  cases,  the  /3-reduction  substitutes  a  LF  term  of  type  exp  in 
the  body  of  the  redex  and  therefore,  the  result  cannot  contain  additional  /3-redices.  This  suggests 
that  it  is  never  the  case  that  the  y3-reductions  are  multiplicated  in  avalanche,  and  therefore  that 
Statman’s  theorem  does  not  apply  in  this  case. 

However,  that  the  reconstruction  effort  is  linear  in  the  term  size  remains  a  surprise  that  we 
attribute  to  the  fact  that  our  experiments  do  not  make  extensive  use  of  quantification.  We  expect 
similar  situations  to  occur  in  most  practical  situations  involving  PCC  and  first-order  logics. 
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12  Related  Work 


We  are  not  the  first  to  address  the  elimination  of  redundancy  in  proof  representations.  Miller  [11] 
approaches  the  problem  by  noting  that  it  should  be  possible  to  greatly  simplify  the  representation 
of  proofs  in  classical  logic  by  simply  recording  the  substitutions  that  were  performed  when  building 
the  proof  instead  of  recording  all  the  basic  proof  steps.  For  this  purpose  he  introduces  a  new  proof 
structure  called  expansion  trees.  While  expansion  tree  representation  of  proofs  are  indeed  compact, 
proof  checking  is  more  expensive  because  some  (directed)  search  still  needs  to  be  done. 

Th('  redundancy  of  representation  that  we  noticed  for  LF  proof  representation  generates  us¬ 
ability  problems  for  implementations  of  logic  programming  languages  or  proof  assistants  based  on 
LF  or  n'lated  type-systems.  Without  a  form  of  implicit  representation  the  interaction  with  these 
sysl(Mns  is  very  verbose.  This  led  the  implementors  to  consider  implicit  representations  that  are 
similar  in  spirit  to  the  one  presented  in  this  report. 

For  ('xample,  the  LEGO  [7,  18]  and  Coq  [3]  proof  assistants  implement  algorithms  for  argument 
syntlu'sis  and  term  reconstruction.  However,  for  the  task  of  representing  proofs  these  algorithms  are 
both  l(\ss  effective,  in  the  sense  that  fewer  proof  subterms  can  be  omitted,  and  less  efficient.  They 
are  l(\ss  effective  because  the  only  arguments  that  can  be  omitted  from  an  application  are  those 
that  can  be  inferred  from  other  arguments  of  the  same  application.  This  means  that  an  application 
of  fh('  t(Tni  eqld  :  He  :  exp.pf  (=  e  e)  must  always  be  explicit  even  though  the  argument  can 
u.sually  !){'  recovered  from  the  context.  These  algorithms  are  also  less  efficient  than  ours  because 
th(\v  implement  more  general  unification  algorithms  that  lift  some  of  the  syntactic  restrictions  that 
w('  imj)ose. 

The  implementation  of  Elf  [17],  a  logic  programming  language  based  on  LF,  contains  a  recon¬ 
struction  algorithm  that  is  similar  to  the  one  presented  here  in  the  sense  that  missing  arguments 
can  be  recovered  also  from  the  context,  not  only  from  the  other  arguments.  In  fact,  the  Elf  recon¬ 
struction  algorithm  is  much  more  powerful  than  ours  because  it  does  not  impose  any  restrictions 
on  which  types  and  terms  can  be  missing  from  the  proof.  In  particular,  the  whole  proof  might 
be  missing,  in  which  case  Elf  tries  to  reconstruct  it.  To  achieve  this  level  of  flexibility.  Elf  type 
reconstruction  employs  depth-first  search  and  higher-order  unification  with  dependent  types  [4], 
followed  by  a  constraint  solver  [16,  15].  An  alternative  characterization  of  our  proof  checking  pro¬ 
cess  is  as  a  proof  reconstruction  instance  where  enough  of  the  structure  of  the  proof  is  given  to 
avoid  the  need  for  search,  to  reduce  higher-order  unification  to  a  simple  extension  of  first-order 
unification  that  respects  bound  variables  and  to  ensure  that  all  constraints  that  are  generated  have 
the  simple  rigid-rigid  or  flex-rigid  form  that  can  be  solved  eagerly.  These  simplifications  enable  us 
to  implement  a  more  efficient  reconstruction  algorithm. 

Because  higher-order  unification  is  undecidable  [6]  and  expensive  in  general.  Miller  [10]  proposes 
syntactic  restrictions  so  that  to  ensure  that  the  only  unification  problems  that  occur  can  be  solved 
by  a  simple  extension  of  the  first-order  unification,  as  in  our  case.  This  approach  is  the  approach 
taken  in  the  language  Unfortunately,  these  restrictions  are  too  strict  for  our  purposes  because 
they  prevent  the  free  use  of  higher-order  abstract  syntax  for  the  representation  of  predicates  and 
proofs.  This  obstacle  can  be  overcome  by  implementing  term  level  substitution,  but  only  at  the 
expense  of  more  complicated  programs  and  a  significant  loss  in  performance  [8,  9].  We  too  recognize 
the  benefits  of  implementing  the  reconstruction  algorithm  for  a  syntactically-restricted  subset  of 
LF,  but  we  do  it  in  such  a  way  that  any  (explicit)  LF  term  can  still  be  type-checked  in  our  system. 
This  does  not  limit  the  available  language  and  programming  techniques  but  might  reduce  the 
effectiveness  of  the  term  compaction  algorithms  in  certain  cases. 

Even  though  there  has  been  a  significant  amount  of  work  in  term  reconstruction,  we  were  not 


66 


able  to  identify  previous  work  on  the  dual  problem  of  proof  compaction. 


13  Conclusion 

In  this  report  we  have  presented  algorithms  for  the  representation  and  validation  of  logical  proofs. 
Such  techniques  are  important  in  situations  where  logical  proofs  must  be  manipulated  explicitly 
^  such  as  in  the  case  of  a  theorem  prover  that  generates  witnesses  of  successful  derivations,  or  in  the 

case  of  Proof-Carrying  Code. 

The  algorithms  presented  here  are  derived  from  the  representation  and  typechecking  algorithm 
^  of  the  Edinburgh  Logical  Framework.  The  major  advantages  that  we  achieve  with  this  choice  is  that 

the  algorithms  are  parameterized  by  the  logic  of  interest  and  therefore  only  one  implementation  is 
required  for  a  large  range  of  logics.  In  particular  this  is  the  case  for  all  our  current  PCC  experiments, 
ranging  from  extensions  to  operating  system  kernel  to  extensions  to  safe  programming  languages 
to  active  network  components.  Another  major  benefit  of  LF  is  that  all  the  complications  due  to 
parametric  and  hypothetical  proofs  are  shifted  to  the  framework  by  using  higher-order  syntax. 

Even  though  the  pure  LF  representation  is  not  optimal  in  terms  of  size  and  validation  time,  our 
implicit  representations  achieve  much  improved  results.  It  is  an  interesting  exercise  to  analyze  the 
behavior  of  the  representation  and  reconstruction  algorithms  for  each  rule  in  a  given  logic.  Such 
an  analysis  reveals  that  for  all  first-order  logic  constructs,  both  the  implicit  representation  and 
reconstruction  are  optimal  in  the  sense  that  nothing  more  could  be  saved  by  algorithms  that  are 
specialized  to  the  given  logic.  This  practically  says  that  we  achieve  performance  comparable  to 
special  purpose  algorithms  by  using  general  algorithms  parameterized  by  the  logic. 

A  major  contribution  of  the  work  presented  in  this  report  is  a  sound  reconstruction  algorithm 
that  is  able  to  reconstruct  and  typecheck  LF  terms  with  missing  subterms.  The  power  of  the 
algorithm  consists  on  being  able  to  work  with  implicit  representations  that  are  15  times  smaller 
than  the  original  LF  representations.  A  notable  feature  of  the  reconstruction  algorithm  is  that  the 
reconstruction  time  is  much  smaller  than  the  time  required  for  checking  the  full  LF  representation, 
in  the  cases  when  the  type  is  known  to  be  well-formed.  We  have  measured  reductions  of  about  on 
order  of  magnitude  in  the  typechecking  time  and  of  about  35%  in  the  space  required  for  typechecking 
when  using  explicit  substitutions. 

Accompanying  the  reconstruction  algorithm  are  several  algorithms  that  can  be  used  to  produce 
implicit  representations  of  full  LF  terms.  Among  these,  two  are  very  simple  and  syntax  directed 
and  produced  near  optimal  results. 

On  the  implementation  front,  we  adapted  the  explicit  substitution  method  to  the  case  of  de¬ 
pendent  type  reconstruction  and  we  integrated  it  with  an  effective  occurs-check  optimization  and  a 
memory  management  optimization.  Finally  we  described  a  portable  binary  encoding  that  attempts 
to  further  minimize  the  size  of  LF  terms. 

4  Although  we  have  made  significant  progress  in  the  size  of  the  representation  and  the  validation 

eflfort  over  pure  LF,  there  is  certainly  room  for  further  improvement.  To  discover  these  opportuni¬ 
ties,  we  want  to  continue  experimenting  with  the  representation  and  reconstruction  algorithms  for 
•  more  diverse  and  for  larger  problems.  The  purpose  of  such  experiments  would  be  to  further  substan¬ 

tiate  our  expectations  that  the  improvements  due  to  the  implicit  representations  are  super-linear 
and  that  the  reconstruction  time  is  linear  on  the  problem  size. 

One  interesting  direction  for  future  work  is  to  experiment  with  representations  of  proofs  in 
higher-order  logics.  It  is  likely  that  the  improvements  that  we  measured  for  first-order  logics  do  not 
translate  directly  to  higher-order  logics,  and  that  even  more  sophisticated  reconstruction  algorithms 
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can  be  devised.  It  would  be  interesting  to  see  if  the  reconstruction  time  is  a  linear  function  of  the 
term  size  also  in  the  case  of  proofs  in  higher-order  logics. 

We  have  claimed  that  the  local  and  the  one-bit  global  erasure  algorithms  can  be  at  the  base  of 
efficient  representation  algorithms  that  achieve  incremental  construction  of  proof  representations 
without  ever  generating  the  full  representation.  An  interesting  experiment  would  be  to  instrument 
an  actual  theorem  prover  to  maintain  proof  representations  of  the  intermediary  results  and  to 
combine  them  as  it  progresses  toward  the  final  proof. 
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